Overview

JoCERT has issued an alert regarding critical command injection vulnerabilities discovered in HPE Aruba’s 501 Wireless Client Bridge. The vulnerabilities, tracked as CVE-2024-54006 and CVE-2024-54007, allow authenticated attackers with administrative privileges to execute arbitrary commands on the device’s underlying operating system.

These flaws have been rated as high severity (CVSS score: 7.2) and pose a significant risk if left unaddressed.

A publicly released proof-of-concept (PoC) exploit further amplifies the urgency for organizations using affected devices to take immediate action.

Vulnerabilities Overview

HPE Aruba Networking has confirmed the existence of multiple command injection vulnerabilities in the web interface of the 501 Wireless Client Bridge. Below is a detailed breakdown of these vulnerabilities:

• CVE-2024-54006: Exploitation enables attackers to execute arbitrary commands as privileged users.
• CVE-2024-54007: Similarly, this flaw allows attackers to run commands remotely with administrative credentials.

Both vulnerabilities:

• Require administrative authentication credentials to exploit.
• Allow attackers to gain full control over the device upon successful exploitation.
• Impact the confidentiality, integrity, and availability of the device.

Affected Software Versions

The vulnerabilities affect the following software versions:

• HPE Aruba 501 Wireless Client Bridge: Versions V2.1.1.0-B0030 and below.

Devices running software versions higher than V2.1.2.0-B0033 are not impacted. Any other HPE Aruba Networking products not explicitly mentioned remain unaffected.

Severity and Exploitability

• Severity: High (CVSS score: 7.2)
• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
• Exploitability: Exploitation requires authenticated administrative credentials. However, once exploited, attackers gain full control of the device, potentially enabling malicious activities such as data exfiltration, lateral movement, and network disruption.
• Public Discussion: A proof-of-concept exploit script has been released publicly, making these vulnerabilities more accessible to attackers.

Mitigation and Recommendations

To safeguard against these vulnerabilities, organizations should follow these steps:

1. Upgrade to a Fixed Version:
   • Update affected devices to software version V2.1.2.0-B0033 or later. The fixed software can be downloaded from the HPE Networking Support Portal.

2. Restrict Management Interfaces:
   • Limit access to the Command Line Interface (CLI) and web-based management interfaces to a dedicated Layer 2 VLAN or secure them with Layer 3 firewall policies.

3. Audit Network Devices:
   • Conduct a thorough security audit of all Aruba devices within your network to identify any unauthorized access or misconfigurations.

4. Strengthen Authentication Mechanisms:
   • Enforce strong administrative passwords.
   • Regularly rotate administrative credentials to minimize the risk of unauthorized access.

5. Monitor for Suspicious Activity:
   • Implement robust monitoring to detect any unusual or unauthorized access attempts to the 501 Wireless Client Bridge.

6. Stay Informed:
   • Subscribe to HPE’s Security Bulletin alerts to receive updates about future vulnerabilities and patches.

Technical Details of the Vulnerabilities

CVE-2024-54006

• Description: Multiple command injection vulnerabilities exist in the web interface of the 501 Wireless Client Bridge, allowing attackers to execute arbitrary commands as a privileged user. Exploitation requires administrative authentication credentials.
• CVSS Base Score: 7.2
• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE-2024-54007

• Description: Similar to CVE-2024-54006, this vulnerability allows authenticated attackers to execute commands on the device’s underlying operating system via the web interface.
• CVSS Base Score: 7.2
• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

Both vulnerabilities were discovered and reported by Nicholas Starke of HPE Aruba Networking SIRT and Hosein Vita.

Workarounds

For organizations unable to immediately update to the fixed version, the following workarounds are recommended:

• Restrict Network Access: Isolate the device management interfaces to a secure VLAN or subnet.
• Firewall Rules: Configure Layer 3 and above firewall policies to limit access to the management interfaces.
• Monitoring and Logging: Enable detailed logging to monitor for unusual administrative activities.

These workarounds are temporary and should not replace patching, which is the most effective mitigation strategy.

Final Notes

These command injection vulnerabilities in HPE Aruba’s 501 Wireless Client Bridge underline the importance of proactive cybersecurity practices. With the rise of publicly disclosed exploits, organizations must act quickly to mitigate risks by updating vulnerable devices, monitoring for threats, and enforcing strict access controls.

Failure to address these vulnerabilities could result in compromised devices, data breaches, and disrupted operations. Take immediate action to protect your network and maintain the integrity of your systems.

Source: https://jocert.ncsc.jo/EN/ListDetails/Security_Alerts__Advisorites/1203/87

https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04763en_us&docLocale

The post  JoCERT Issues Warning on Exploitable Command Injection Flaws in HPE Aruba Products appeared first on Cyble.

Blog – Cyble – ​Read More

Editor’s note: The current article is authored by Mauro Eldritch, offensive security expert and threat intelligence analyst. You can find Mauro on X.

Recently, during October and November, we observed a rise in North Korean activity employing a well-known and distinctive technique: staging job interview processes to spread multiple malware families.

This signature technique was previously used to distribute QRLog and Docks /RustDoor, and is now delivering BeaverTail and InvisibleFerret. In this first article, we will conduct a technical dissection of the latter.

The Beaver

These malicious components do not simply appear randomly among the files of questionable pirated software, lying in wait for their victim. Instead, they are part of an organized effort targeting the technological, financial, and cryptocurrency sectors, with developers as the primary focus. By staging fake job interviews, threat actors aim to spread malware disguised either as coding challenges (or their dependencies) or video call software, in a campaign now known as Contagious Interview or DevPopper.

One of the implants distributed is BeaverTail, a stealer and loader written in obfuscated JavaScript and delivered as an NPM module. While not the focus of this article, BeaverTail downloads a customized portable Python environment (“p.zip”) and later deploys InvisibleFerret as its next stage, which is the main subject of this research.

The Ferrets

InvisibleFerret is a Python-based malware that, at first glance, shows a disorganized structure and unnecessary escaping sequences, giving a glimpse of what lies ahead if we dare to explore the code further. A quick look reveals a compact initialization of hardcoded constants used to install dependencies via pip, which are later reused multiple times throughout its execution.

As expected from malware of its kind, InvisibleFerret does not generate an output trail or a logfile of its actions. Its silent nature, combined with a somewhat difficult-to-read codebase, led me to add verbosity to its functions and expand some of its compressed syntax and overly compact one-liners for better readability, creating PrettyVisibleFerret. This version is more talkative and easier to read for everyone, but still executes malicious instructions and should be handled with care.

After submitting the malware for analysis to ANY.RUN’s Interactive Sandbox, the first thing this mischievous ferret attempts is to gather basic information about the victim, such as geolocation — by querying legitimate services like ip-api.com (commonly used by other malware and even drainers like “ETH Polygon BNB”) — as well as system details like OS release, version, hostname, and username, before finally generating a unique ID.

After the /keys endpoint is accessed, the ferret jumps to the next C2 server in the infection chain, registering the host by its name and tagging it based on its OS.

Our host is now registered within the adversary infrastructure, but before continuing along the infection chain and following the white ferret, let’s review the traffic and noise generated so far.

Up to this point, most of the traffic is legitimate, either originating from the package manager pip — even if invoked by the malware itself — or directed to legitimate services like ip-api. However, we can observe three streams to two C2 servers using ports 1244 and 1245, which are correctly flagged as ‘unusual’ by ANY.RUN.

Aside from the unusual port, there’s another interesting yet careless detail: the Python package ‘requests’ is using its default User-Agent (python-requests/2.25.1 in this case), making it easier to dissect the traffic, narrow down destinations, and map the adversary’s infrastructure.

What happens next is better understood by examining the code rather than dry-running the sample in a sandbox filled with placebo files. We’ll let the simulation run and return later to gather indicators and behaviors.

Be advised: much of this malware is held together by sticks and mud, so expect confusing and poor practices, such as ‘obfuscating’ C2 addresses within a sliced Base64-encoded string.

The Session class implements FTP as one of its exfiltration methods, relying on the Python ftplib package. If the package is not found, it attempts to install it. Once again, the exfiltration host is poorly hidden in plain sight within a Base64-encoded string.

The ferret then moves on to assess what to steal, declaring five extensive arrays: some designed to list extensions, files, directories, and patterns to ignore, and others specifying what to target.

The Shell class implements new and dangerous methods allowing our fluffy adversary to run arbitrary commands sent by the attacker and downloading and executing a subsequent stage of the infection chain.

Remember ftplib? It comes into play again in the o_ftp method, which opens FTP connections. Meanwhile, the ssh_upload method handles the data exfiltration process.

This process — defined by the method storbin — is somewhat complex. Files with specific extensions, such as compressed files or virtual machine disk files, are sent directly to the server via the FTP STOR command. Other files are obfuscated using XOR with a specific key before being transferred to the server. While not a robust encryption method, this technique adds a basic layer of protection.

Files are compressed using py7zr in 7z format (on Windows) or zip format with pyzipper (on Unix), with the password defaulting to ‘2024’ if none is provided.

Finally, down_any and ssh_any, download and execute AnyDesk, a legitimate remote desktop software, to establish persistence.

Two notable mentions are the ssh_env function, responsible for detecting the running OS and mapping points of interest in the corresponding file system: Documents and Downloads on Windows and /Volumes, /home, and /vol on Unix;

and the ssh_kill one, which kills Google Chrome and Brave browsers processes.

However, this tricky ferret doesn’t stop there—it has more in store for the victim’s browsers. After identifying the local browser, it defines specific paths to extract user data, such as profiles, cookies, credentials, and browsing history. Dedicated classes are implemented for Chrome, Chromium, Opera, Brave, Edge, and Vivaldi.

A set of browser extensions is targeted to exfiltrate their data, primarily including crypto exchange and wallets like Metamask, multi factor authentication apps like Google Authenticator and password managers like 1Password.

Telegram is also used as an exfiltration channel for files, directly invoking the Bots API sendDocument endpoint. Since the connection and queries are handled entirely locally, PrettyVisibleFerret can reveal the Chat ID and Bot Secret Token used, enabling interaction with the bot and potentially reconfiguring or shutting it down through @BotFather, Telegram’s Bot Manager.

On Windows systems, the ferret imports (or attempts to install if missing) pywin32 (provides Windows API access), psutil (used to retrieve system information and manage processes), pyWinhook (a library for keyboard and mouse event handling), and pyperclip (used to manage the clipboard). The last two are pretty self-explanatory.

Pyperclip is specifically used to monitor clipboard changes and exfiltrate its content. This is useful to capture passwords, keys and other secrets.

PyHook is used to hook into the Windows operating system to capture user input events, monitoring both the keyboard (keystrokes) and the mouse.

And so the code reaches its EOF. Let’s return to the simulation to examine the resulting IOCs and see what conclusions we can draw from them.

Chasing a Ferret: IOCs & TTPs

This playful threat left quite a mess, so let’s summarize the indicators gathered so far. Remember that the earlier stage, BeaverTail, downloads a portable Python runtime (‘p.zip’) from the /pdown endpoint to run InvisibleFerret, meaning indicators from that activity are also included.

SHA256:47830f7007b4317dc8ce1b16f3ae79f9f7e964db456c34e00473fba94bb713eb

SHA256:6a104f07ab6c5711b6bc8bf6ff956ab8cd597a388002a966e980c5ec9678b5b0

Filename:p.zip

IPV4:147[.]124[.]214[.]129

IPV4:173[.]211[.]106[.]101

URL:http://147[.]124[.]214[.]129:1244

URL:http://147[.]124[.]214[.]129:1244/keys

URL:http://147[.]124[.]214[.]129:1244/pdown

URL:http://173[.]211[.]106[.]101:1245

URL:http://173[.]211[.]106[.]101:1245/brow

URL:http://173[.]211[.]106[.]101:1245/bow

URL:http://173[.]211[.]106[.]101:1245/adc

These indicators can be observed in action through ANY.RUN’s timeline, providing a structured view of how the malware operates in a step-by-step view.

As previously discussed, not every queried IP or downloaded file is inherently malicious, even if retrieved by malware. Many are legitimate packages, dependencies, or services that benefit the broader community but are sometimes misused by bad actors. We can’t label a tool or artifact as an Indicator of Compromise simply because it’s used by malicious actors.

However, we can trace behaviors, such as “this bad actor uses this API to geolocate victims” or “this actor frequently relies on this remote desktop solution for persistence”. These behaviors are the essence of TTPs: Tactics, Techniques, and Procedures—essentially, how an actor operates and achieves its objectives.

Contextualizing these threats helps researchers and the broader community standardize threat behaviors, improving their understanding and making collaboration more effective. For example, a threat actor (or malware) querying ip-api to geolocate a victim and another one using a different service for the same purpose both fall under the T1016 technique, “System Network Configuration Discovery”, in general terms. While their actions at a more specific level are classified as Procedures, grouping them under a shared taxonomy significantly reduces information fragmentation and organizes data in a structured manner.

The same applies to the other behaviors discussed in this article, such as using an unusual port to connect to a service. These actions fall under T1571, regardless of the specific port, protocol, or direction used.

ANY.RUN’s direct integration with the MITRE ATT&CK Matrix simplifies the TTP mapping process by assembling it in real time.

That said, I think we’ve had enough playtime with our pet—it’s time to put the ferret back in its cage.

Ferret Fever

These campaigns involve large investments not only in infrastructure and human resources but also in developing quite convincing scenarios, like a fake job interview where you are asked to run a coding challenge or download a meeting software, which may seem completely normal if you don’t overthink it.

Always double-check job offers, don’t run software from unknown origins on your company equipment, stay safe out there, and whatever your situation is, don’t befriend ferrets, invisible or pretty visible ones alike.

About ANY.RUN

ANY.RUN helps more than 500,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, YARA Search and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster.  

With ANY.RUN you can: 

• Detect malware in seconds
• Interact with samples in real time
• Save time and money on sandbox setup and maintenance
• Record and study all aspects of malware behavior
• Collaborate with your team 
• Scale as you need

Get a 14-day free trial to test all features of ANY.RUN’s Interactive Sandbox →

The post InvisibleFerret Malware: Technical Analysis appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Overview

Fortinet, a global leader in cybersecurity solutions, recently released a critical advisory addressing a significant vulnerability (CVE-2024-55591) in its FortiOS and FortiProxy products. This flaw, which has a CVSSv3 score of 9.6, is categorized as a critical authentication bypass vulnerability and is currently being exploited in the wild.

Attackers leveraging this vulnerability can potentially gain super-admin privileges by exploiting weaknesses in the Node.js WebSocket module, making this a high-stakes issue for organizations relying on Fortinet’s products.

This blog provides a detailed overview of the vulnerability, affected versions, Indicators of Compromise (IOCs), mitigation strategies, and steps for administrators to protect their systems effectively.

The Vulnerability Explained

The CVE-2024-55591 vulnerability stems from an “Authentication Bypass Using an Alternate Path or Channel” issue (CWE-288). An attacker can craft malicious requests to the Node.js WebSocket module, bypass authentication, and gain unauthorized super-admin access. Once exploited, the attacker can perform a wide range of malicious activities, including:

• Creating administrative or local user accounts.
• Modifying firewall policies, addresses, or system settings.
• Establishing Secure Sockets Layer Virtual Private Network (SSL VPN) tunnels to access internal networks.

Affected Products and Versions

The vulnerability impacts the following versions of FortiOS and FortiProxy products:

FortiOS

• Versions 7.0.0 through 7.0.16 are affected.
• Versions 7.6, 7.4, and 6.4 are not affected.

FortiProxy

• Versions 7.0.0 through 7.0.19.
• Versions 7.2.0 through 7.2.12.
• Versions 7.6 and 7.4 are not affected.

Solution:

• Upgrade FortiOS to version 7.0.17 or later.
• Upgrade FortiProxy to versions 7.0.20 or 7.2.13 or later.

How Attackers Exploit the Vulnerability

Attackers exploit this vulnerability by sending malicious WebSocket requests to bypass authentication controls. They can target administrative accounts by guessing or brute-forcing usernames. Once access is gained, they perform the following malicious actions:

• Create random user accounts such as “Gujhmk” or “M4ix9f”.
• Add these accounts to administrative or VPN groups.
• Use SSL VPN connections to infiltrate the internal network.

Indicators of Compromise (IOCs)

Fortinet has shared some key IOCs that organizations should monitor to identify potential attacks.

Log Entries

Look for the following types of suspicious log entries in your system:

1. Successful Admin Logins:

type=”event” subtype=”system” level=”information” logdesc=”Admin login successful”

user=”admin” ui=”jsconsole” srcip=1.1.1.1 dstip=1.1.1.1 action=”login” status=”success” 

msg=”Administrator admin logged in successfully from jsconsole”

• Unauthorized Configuration Changes:

type=”event” subtype=”system” level=”information” logdesc=”Object attribute configured”

user=”admin” ui=”jsconsole(127.0.0.1)” action=”Add”

msg=”Add system.admin vOcep”

Suspicious IP Addresses

Attackers have been observed using the following IP addresses to launch attacks:

• 45.55.158.47 (most commonly used)
• 87.249.138.47
• 155.133.4.175
• 37.19.196.65
• 149.22.94.37

It’s important to note that these IP addresses are not fixed sources of attack traffic; they are often spoofed and may not represent the actual origin.

Recommended Actions

1. Update Immediately

If your organization is using affected versions of FortiOS or FortiProxy, the most effective solution is to upgrade to the latest secure versions. Fortinet has provided tools to assist with upgrading, which can be found on their official site.

2. Mitigations for Immediate Protection

If an upgrade cannot be performed immediately, consider implementing the following mitigations:

• Disable HTTP/HTTPS Administrative Interfaces: This reduces the exposure of management interfaces to the internet.
• Restrict Access with Local-In Policies:
  Limit access to the administrative interface by allowing only trusted Ips
• Use Non-Standard Admin Usernames: To make brute-force attacks more difficult, avoid predictable or default usernames for administrative accounts.

Exploitation in the Wild

Reports indicate active exploitation of this vulnerability. Threat actors have been observed creating random administrative or local user accounts, such as:

• Gujhmk
• Ed8x4k
• Alg7c4

These accounts are often added to SSL VPN user groups to establish tunnels into internal networks, making it critical to monitor for unauthorized account creation.

Best Practices for Enhanced Security

1. Enable Logging and Monitoring:
   Continuously monitor system logs for any unauthorized administrative activity, suspicious configuration changes, or unexpected VPN connections.
2. Conduct Regular Vulnerability Scans:
   Perform routine scans to identify and patch other vulnerabilities within your network infrastructure.
3. Adopt a Zero Trust Approach:
   Limit user privileges to the minimum required and enforce strict access controls, especially for administrative tasks.
4. Educate Your Team:
   Ensure that your IT and security teams are aware of this vulnerability and trained to respond to potential threats.
5. Implement Multi-Factor Authentication (MFA):
   Although this vulnerability bypasses traditional authentication, MFA adds an additional layer of security that can mitigate other attack vectors.

Conclusion

The CVE-2024-55591 vulnerability emphasizes the critical need for organizations to stay ahead of emerging threats. With attackers actively exploiting this flaw to gain super-admin access, the risks to your infrastructure and data cannot be overstated. Organizations using FortiOS and FortiProxy must act immediately. Patching systems and implementing mitigations isn’t optional; it’s imperative.

It’s not just about reacting to vulnerabilities—it’s about adopting a proactive and layered approach to cybersecurity. Leveraging tools like multi-factor authentication, real-time log monitoring, and Zero-Trust architectures can significantly reduce the risk of exploitation.

The broader lesson here is clear: vulnerabilities are inevitable, but breaches don’t have to be. By staying informed, investing in advanced threat detection systems, and fostering a security-first mindset within your organization, you can not only address immediate threats but also build resilience against future ones.

As cyber threats grow more advanced, are you prepared to meet them head-on? Strengthening your defenses today will determine your security tomorrow.

Let this be a reminder to continuously innovate and adapt in the face of an ever-changing threat landscape.

Your next step could define the safety of your organization.

Source:

• https://www.csa.gov.sg/alerts-advisories/alerts/2025/al-2025-004
• https://www.fortiguard.com/psirt/FG-IR-24-535
• https://nvd.nist.gov/vuln/detail/CVE-2024-55591

The post Fortinet Zero-Day CVE-2024-55591 Exposed: Super-Admin Access Risk appeared first on Cyble.

Blog – Cyble – ​Read More

Quantum computers remain a highly exotic technology, used by a very small number of companies for very specific computational tasks. But if you search for “quantum computer news”, you might get the impression that all the major IT players have already armed themselves with quantum technology, and that any day now hackers will start using it to crack encrypted communications and manipulate digital signatures. The reality is both less tense and more complex — but such nuances don’t make the headlines. So, who’s been making all the noise about quantum hacking?…

Mathematicians

Although the respected American mathematician Peter Shor meant to create neither hype nor panic, it was he who, back in 1994, proposed the idea of an entire family of algorithms for solving computationally complex mathematical problems on a quantum computer. Chief among these was the problem of factoring into prime numbers. For sufficiently large numbers, a classical computer would need… centuries to find a solution — which serves as the foundation of cryptographic algorithms like RSA. However, a powerful quantum computer using Shor’s algorithm could solve this problem much faster. Although such a computer was still a dream in 1994, Shor’s idea captured the imagination of hackers, physicists, and of course, journalists. Shor recalls that when he first presented his idea at a conference in 1994, he hadn’t yet completely solved the factorization problem — the final version of his research was only published in 1995. Nevertheless, just five days after his presentation, people were confidently proclaiming that the factorization problem had been solved.

Startups

For many years, the quantum threat was considered just a distant possibility. The number of quantum bits (qubits) required to break cryptography was estimated to be in the thousands or millions, while experimental quantum computers were still in single digits. The situation changed in 2007, when the Canadian company D-Wave Systems demonstrated the “first commercial quantum computer”, boasting 28 qubits, with a plans to scale up to 1024 qubits by the end of 2008. The company predicted that by 2009 it would be possible to rent quantum computers for cloud computations — using them for risk analysis in insurance, modeling in chemistry and materials science, as well as for “government and military needs”. By 2009, D-Wave expected to achieve quantum supremacy — when a quantum computer could solve a problem faster than a classical one.

The quantum community had to spend years dealing with the company’s claims. The principle of quantum annealing, used in D-Wave systems, wasn’t even considered a quantum effect, and its existence was only proven in 2013 — albeit with serious reservations. Meanwhile, the magnitude (and even the existence) of quantum supremacy continued to be a subject of debate even longer. In any case, D-Wave systems can run neither Shor, nor Grover’s algorithms, making them unsuitable for cryptanalysis tasks. The company continues to build computers (or, rather, “quantum annealers”) with ever-increasing numbers of qubits, but their practical application remains very limited.

Cyber agencies

When the U.S. National Security Agency (NSA) issues warnings and advice on a problem, it’s a good reason to take that problem seriously. That’s why the NSA’s 2015 recommendation urging companies and governments to begin transitioning to quantum-resistant encryption was taken as a signal that the arrival of practical quantum computers might just be round the corner. This warning came as a surprise: at the time, the largest number that had been factored using Shor’s algorithm on a quantum computer was… 21. This fueled speculation that the NSA knew something about quantum computers that the rest of the world didn’t.

Now, nearly a decade later, we can be fairly confident that the NSA was sincere in its subsequent explanations, released six months later: they were simply warning of a potential danger ahead of time. After all, equipment purchased for government agencies tends to remain in service for decades, so systems should be upgraded well in advance to avoid future vulnerabilities. Around the same time, NIST announced a competition to develop a standardized set of quantum-resistant algorithms. In 2024, this new standard was adopted.

Internet giants

Many major IT companies, such as Google and IBM, have shown interest in quantum computing — and invested in it. At the end of the 20^th century, IBM labs created the first working quantum computer with two qubits. But it was Google that, in 2019, announced the long-awaited achievement of quantum supremacy. Their experimental 53-qubit computer, Sycamore, could reportedly solve a problem in not much over three minutes that would take a classical supercomputer 10,000 years. However, IBM disputed this claim, arguing that this problem was purely synthetic, designed for quantum computers specifically, and having no real-world application. For a supercomputer to solve the same problem, it would simply have to simulate a quantum one, which would be quite useless — not to mention slow. IBM further stated that with sufficient disk space, a classical supercomputer could solve the same problem with greater accuracy and in a relatively short time: no more than 2.5 days.

Even the original creator of the term “quantum supremacy”, Professor John Preskill, criticized Google’s excessive use of the phrase, noting its popularity with journalists and marketers. As a result, its intended technical use has been obscured.

Governments

Security experts, including the NSA, have repeatedly emphasized that the quantum threat is a reality — even in the absence of a practical quantum computer. One possible scenario is well-resourced malefactors storing an encrypted copy of valuable data today in order to decrypt it in the future when quantum computers become viable. Such an attack, known as harvest now, decrypt later, is often mentioned in the context of the “quantum race”, and in 2022, the U.S. government created quite a stir by claiming to already be facing SNDL attacks. Experts from the post-quantum security firm QuSecure also referred to SNDL attacks as a “common practice” in an article ominously titled Quantum apocalypse.

Meanwhile, the White House coined the term CRQC (Cryptanalytically Relevant Quantum Computer) and ordered U.S. agencies to switch to post-quantum encryption algorithms no later than 2035.

Enthusiasts

Quantum computers are complex, unique physical devices that often require extreme cooling. As a result, small firms and individual researchers have a hard time keeping up in the quantum race; however, that doesn’t stop some from trying. In 2023, statements from a researcher named Ed Gerck, founder of a company called Planalto Research, created a small buzz. According to Gerck, his company managed to perform quantum computations on a commercial Linux desktop with capital costs of less than a thousand dollars and without using cryogenics. The author claimed to have broken a 2048-bit RSA key despite these limitations. Interestingly, Gerck allegedly developed his own algorithm to do this, rather than using Shor’s. Cryptographers and developers of quantum computers have repeatedly demanded proof of Gerck’s claims but received only excuses in response. Gerck’s paper has in fact been published; however, experts note serious methodological flaws and speculative elements.

And, of course, the press

A study by researchers at Shanghai University directly linking quantum computing to encryption cracking was published in China in September 2024. However, it only caused a splash worldwide after a November article in the South China Morning Post. This article claimed that the Chinese scientists had successfully broken “military-grade encryption”, and this headline was carelessly replicated by other media outlets.

In fact, the authors of the study did target encryption, but solved a much more modest problem — they cracked 50-bit ciphers related to AES (Present, Gift-64, and Rectangle). Interestingly, they used one of the latest models from the very same D-Wave, using classical algorithms to compensate for its limitations compared to a full-fledged quantum computer. This study is scientifically novel, but its practicality in breaking real-world encryption is highly questionable. In addition to the deficit of qubits, the incredibly long classical pre-calculations required to crack real 128 or 256-bit keys remains an obstacle.

This wasn’t the first time researchers have claimed success in breaking encryption, but an earlier, similar announcement in 2022 received little attention.

Internet giants (yes, again)

A new round of speculation began with Google’s recent announcement of its Willow chip. The developers have claimed that they’ve managed to solve one of the key problems in scaling quantum computing — error correction. This problem arises because it’s extremely challenging to read the state of a qubit without making errors or disturbing its entanglement with other qubits. Therefore, calculations are often run multiple times, and many “noisy” physical qubits are combined into a single “perfect” logical one. Despite these measures, as the number of qubits increases, errors grow exponentially, making the system increasingly fragile. In contrast, the new chip demonstrates the opposite behavior — as the number of qubits increases, errors are reduced.

Willow has 105 physical qubits. Of course, this is far from enough to break modern encryption. According to the Google researchers themselves, their computer would need millions of qubits to become a CRQC.

But such trifles didn’t stop other researchers from declaring the imminent death of modern cryptography. For example, researchers at the University of Kent have estimated that advances in quantum computing could require the Bitcoin network to shut down for 300 days in order to update to quantum-resistant algorithms.

Welcome to reality

Leaving the mathematical and technical aspects aside, it’s worth emphasizing that, as of right now, cracking modern encryption using quantum computers is still impossible, and this is unlikely to change in the near future. However, sensitive data that will remain valuable for years to come should be encrypted with quantum-resistant (post-quantum) algorithms today to avoid potential future risks. Several major IT regulators have already issued recommendations on transitioning to post-quantum cryptography, which should be studied and gradually implemented.

Kaspersky official blog – ​Read More

Key Takeaways

• Cyble Research and Intelligence Labs (CRIL) has identified an ongoing cyberattack – targeting organizations in Germany.
• The attack is initiated through a deceptive LNK file embedded within an archive. When executed by an unsuspecting user, this LNK file triggers cmd.exe to copy and run wksprt.exe, a legitimate executable.
• This executable sideloads a malicious DLL that employs DLL proxying, ensuring the host application continues to operate seamlessly while executing malicious shellcode in the background.
• The shellcode ultimately decrypts and executes the final payload: Sliver, a well-known open-source Red Team/adversary emulation framework.
• Once deployed, Sliver functions as an implant, enabling threat actors to establish communication with the compromised system and conduct further malicious operations, thereby enhancing their control over the infected network.

Overview

Cyble Research & Intelligence Labs (CRIL) recently identified an ongoing campaign involving an archive file containing a deceptive LNK file. While the initial infection vector remains unclear, this attack is likely initiated via spear-phishing email.

The archive file “Homeoffice-Vereinbarung-2025.7z,” once extracted, contains a shortcut (.LNK) file along with several other components, including legitimate executables (DLL and EXE files), a malicious DLL file, an encrypted DAT file, and a decoy PDF. Interestingly, the creation times of most files in the archive are about a year old, with only the lure document being recently created. This suggests that the Threat Actor (TA) has not updated their core components, opting instead to introduce a new lure document to maintain the campaign’s relevance.

Upon execution, the LNK file triggers the opening of a decoy document, masquerading as a Home Office Agreement. This document serves as a lure to deceive the user. Concurrently, the LNK file also executes a legitimate executable, which subsequently performs DLL sideloading. The legitimate executable loads the malicious DLL, which is designed to retrieve and decrypt the shellcode from the DAT file stored in the same extracted archive. This entire process occurs entirely in memory, enabling the attack to evade detection by security products.

The shellcode is designed to decrypt and execute an embedded payload, a Sliver implant—an open-source red teaming and command and control framework employed by the TA for further malicious actions. Upon execution, the implant establishes connections to specific remote servers/endpoints, enabling the TA to conduct additional malicious operations on the victim’s system.

The figure below provides an overview of the infection process.

Technical Details

The attack begins once the victim extracts an archive file, likely delivered via an email attachment, containing several files:

• IPHLPAPI.dll – malicious DLL file
• IPHLPLAPI.dll – renamed legitimate IPHLPAPI.DLL
• ccache.dat – Contains Encrypted Shellcode
• wksprt.lnk  – Shortcut file to load wksprt file
• 00_Homeoffice-Vereinbarung-2025.pdf – Lure document
• Homeoffice-Vereinbarung-2025.pdf.lnk – Main shortcut file

However, only Homeoffice-Vereinbarung-2025.pdf.lnk, disguised as a PDF, is visible, while the other files remain hidden. When the user runs this LNK file, it triggers cmd.exe to execute a series of commands, copying files to specific directories and performing additional tasks. The image below shows the command embedded in the LNK file.

Following the execution of the LNK file, a directory named “InteI” is created within the user’s local app data folder (%localappdata%InteI). A legitimate Windows file, wksprt.exe, from C:WindowsSystem32 is then copied into this newly created InteI directory. Subsequently, the hidden files IPHLPAPI.dll, IPHLPLAPI.dll, and ccache.dat are copied into the “InteI” directory, with their hidden attributes preserved.

To establish persistence on the victim’s machine, wksprt.lnk, one of the files from the extracted folder, is copied to the Startup folder (%appdata%MicrosoftWindowsStart MenuProgramsStartup). This LNK file is designed to execute wksprt.exe, which has been copied to the “InteI” directory, ensuring that the executable runs automatically upon system startup.

Before the final step, the decoy file “00_Homeoffice-Vereinbarung-2025.pdf” is executed to maintain the appearance of a legitimate document being opened.

The lure document is a Home Office Agreement (Homeoffice-Vereinbarung) written in German, serving as a supplementary agreement to an existing employment contract between an organization and an employee, outlining the terms for remote work. Based on the content of this lure document, we believe this campaign is designed to target individuals or organizations in Germany. Furthermore, the initial .7z file was observed to have been uploaded to VirusTotal from a German location, supporting this assessment. Finally, wksprt.exe is launched from the “InteI” directory to carry out further actions.

The malicious DLL file has a very low detection rate, as shown below.

DLL Sideloading and DLL Proxying:

The legitimate executable wksprt.exe sideloads a malicious DLL (IPHLPAPI.dll) from the current directory. The malicious IPHLPAPI.dll then loads a slightly renamed legitimate DLL (IPHLPLAPI.dll), designed to appear authentic. Both DLLs export the same functions, as shown below.

The malicious DLL acts as a proxy, intercepting function calls from the executable and forwarding them to the legitimate DLL, which contains the actual implementation of the function, as shown below.

The forwarding of function calls ensures that the application maintains its normal behavior while allowing the malicious DLL to execute its own code. In addition, the malicious DLL spawns a new thread to read the contents of the file ccache.dat, as shown below.

After the “ccache.dat” file’s content is read, the malicious thread decrypts the malicious data. It employs the following cryptographic APIs for key generation and decryption:

• CryptAcquireContextW
• CryptCreateHash
• CryptHashData
• CryptDeriveKey
• CryptDecrypt

The thread now copies the decrypted content to the newly allocated memory and executes it. The figure below shows the decrypted content of “ccache.dat” and the control transfer to the decrypted content.

The decrypted content is a shellcode that runs another decryption loop to retrieve the actual payload embedded within it, as shown below.

The shellcode is designed to execute the embedded Sliver implant—an open-source red teaming framework used for malicious purposes by the TAs. Once executed, the implant connects to the following endpoints to carry out additional activities on the victim’s system.

• hxxp://www.technikzwerg[.]de/auth/auth/authenticate/samples.html
• hxxp://www.technikzwerg[.]de/auth/auth/authenticate/samples.php

Attribution

While we cannot definitively attribute this campaign to any specific group at this point, the initial infection vector, stager DLL behavior, shellcode injection, and Sliver framework exhibit patterns typically associated with APT29 in past campaigns. Additionally, this group has frequently employed the DLL sideloading technique in its operations. However, the most recent sample analyzed introduces DLL proxying, a technique not previously observed in APT29’s campaigns.

Conclusion

This campaign targets organizations in Germany by impersonating an employee agreement for remote working. Using this lure, the threat actors deploy a deceptive LNK file and malicious components to gain an initial foothold on the victim’s system, leading to its compromise and further exploitation.

By employing advanced evasion techniques such as DLL sideloading, DLL proxying, shellcode injection, and the Sliver framework, the attackers effectively bypass traditional security measures. This multi-stage cyberattack highlights the increasing sophistication and adaptability of threat actors, underscoring the growing complexity of APT operations and the urgent need for enhanced detection and defense strategies.

Yara and Sigma rules to detect this campaign are available for download from the linked Github repository.  

Our Recommendations

• The initial breach may occur via spam emails. Therefore, it’s advisable to deploy strong email filtering systems to identify and prevent the dissemination of harmful attachments.
• Exercise caution when handling email attachments or links, particularly those from unknown senders. Verify the sender’s identity, particularly if an email seems suspicious.
• Use application whitelisting to prevent unauthorized execution of LNK files and other suspicious components.
• Deploy Endpoint Detection and Response (EDR) solutions to identify and block malicious behaviors, such as DLL sideloading and shellcode injection.
• Monitor for anomalous network activities, such as unexpected outbound connections, to detect Sliver framework-related activities.

MITRE ATT&CK® Techniques

Tactic	Technique	Procedure
Initial Access (TA0001)	Phishing (T1566)	The archive file may be delivered through phishing or spam emails
Execution  (TA0002)	Command and Scripting   Interpreter (T1059)	TAs abuse command and script interpreters to execute commands
Persistence  (TA0003)	Registry Run Keys / Startup   Folder (T1547.001	Creates persistence by   adding a lnk to a startup folder
Privilege   Escalation  (TA0004)	Hijack Execution Flow:   DLL Side-Loading (T1574.002)	Execute malicious Dll using Dll Sideloading
Defense Evasion (TA0005)	Obfuscated Files or   Information (T1027.002)	Binary includes encrypted data
Command and Control (TA0011)	Application Layer Protocol: Web Protocols (T1071.001)	Implant communicates with its C&C server

Indicators of Compromise (IOCs)

Indicators	Indicator Type	Description
83a70162ec391fde57a9943b5270c217d63d050aae94ae3efb75de45df5298be	SHA-256	Archive File
f778825b254682ab5746d7b547df848406bb6357a74e2966b39a5fa5eae006c2	SHA-256	LNK file
9b613f6942c378a447c7b75874a8fff0ef7d7fd37785fdb81b45d4e4e2d9e63d	SHA-256	Malicious DLL
86f8a979bd887955f0491a0ed5e00de2f3fe53e6eb5856fb823115ce43b7c0ca	SHA-256	Encrypted .dat file

References

https://lab52.io/blog/2162-2/
https://www.ncsc.gov.uk/files/Advisory%20Further%20TTPs%20associated%20with%20SVR%20cyber%20actors.pdf
https://www.ired.team/offensive-security/persistence/dll-proxying-for-persistence

The post Sliver Implant Targets German Entities with DLL Sideloading and Proxying Techniques appeared first on Cyble.

Blog – Cyble – ​Read More