Feed aggregator

ISC Stormcast For Thursday, April 25th, 2024 https://isc.sans.edu/podcastdetail/8954

Enlarge (credit: Getty Images) On Thursday, Baltimore County Police arrested Pikesville High School's former athletic director, Dazhon Darien, and charged him with using AI to impersonate Principal Eric Eiswert, according to a report by The Baltimore Banner. Police say Darien used AI voice synthesis software to simulate Eiswert's voice, leading the public to believe the principal made racist and antisemitic comments. The audio clip, posted on a popular Instagram account, contained offensive remarks about "ungrateful Black kids" and their academic performance, as well as a threat to "join the other side" if the speaker received one more complaint from "one more Jew in this community." The recording also mentioned names of staff members, including Darien's nickname "DJ," suggesting they should not have been hired or should be removed "one way or another." The comments led to significant uproar from students, faculty, and the wider community, many of whom initially believed the principal had actually made the comments. A Pikesville High School teacher named Shaena Ravenell reportedly played a large role in disseminating the audio. While she has not been charged, police indicated that she forwarded the controversial email to a student known for their ability to quickly spread information through social media. This student then escalated the audio's reach, which included sharing it with the media and the NAACP.Read 5 remaining paragraphs | Comments

Business email compromise (BEC) was the top threat observed by Cisco Talos Incident Response (Talos IR) in the first quarter of 2024, accounting for nearly half of engagements, which is more than double what was observed in the previous quarter.  The most observed means of gaining initial access was the use of compromised credentials on valid accounts, which accounted for 29 percent of engagements. The high number of BEC attacks likely played a significant role in valid accounts being the top attack vector this quarter. Weaknesses involving multi-factor authentication (MFA) were observed within nearly half of engagements this quarter, with the top observed weakness being users accepting unauthorized push notifications, occurring within 25 percent of engagements.  Talos IR Quarterly Trends Report (Q1 2024)An overview of the top attacker trends, malware and the most-targeted industries.Talos IR Trends (Q1 2024).pdf174 KB.a{fill:none;stroke:currentColor;stroke-linecap:round;stroke-linejoin:round;stroke-width:1.5px;}download-circleThere was a slight decrease in ransomware this quarter, accounting for 17 percent of engagements. Talos IR responded to new variants of Phobos and Akira ransomware for the first time this quarter. Manufacturing was the most targeted vertical this quarter, closely followed by education, a continuation from Q4 2024 where manufacturing and education were also two of the most targeted verticals. There was a 20 percent increase in manufacturing engagements from the previous quarter. The manufacturing sector faces unique challenges due to its inherently low tolerance for operational downtime. This quarter, Talos IR observed a wide range of threat activity targeting manufacturing organizations including financially motivated attacks, such as BEC and ransomware, and some brute force activity targeting virtual private network (VPN) infrastructure. The use of compromised credentials on valid accounts was the top observed attack vector within attacks targeting the manufacturing sector this quarter, which represents a change from the previous quarter when the top attack vector observed in these types of engagements was exploiting vulnerabilities in public-facing applications.   Watch discussion on the report's biggest trendsSurge in BEC Within BEC attacks, adversaries will send phishing emails appearing to be from a known or reputable source making a valid request, such as updating payroll direct deposit information. BEC attacks can have many motivations, often financially driven, aimed at tricking organizations into transferring funds or sensitive information to malicious actors.  BEC offers adversaries the advantage of impersonating trusted contacts to facilitate internal spearphishing attacks that can bypass traditional external defenses and increase the likelihood of deception, widespread malware infections and data theft. In one engagement, adversaries performed a password-spraying attack and MFA exhaustion attacks against several employee accounts. There was a lack of proper MFA implementation across all the impacted accounts, leading to the adversaries gaining access to at least two accounts using single-factor authentication. The organization detected and disrupted the attack before adversaries could further their access or perform additional post-compromise activities.    In another cluster of activity, several employees received spear-phishing emails that contained links that, when clicked, led to a redirection chain of web pages ultimately landing on a legitimate single sign-on (SSO) prompt that was pre-populated with each victim’s email address. The attack was unsuccessful because none of the employees interacted with the email, which was likely due to multiple red flags. For example, the email was unexpected and sent from an external email address, and there was small text within the email that referred to the email as a fax, which was all indicators of a phishing attempt. Ransomware trends Ransomware accounted for 17 percent of engagements this quarter, an 11 percent decrease from the previous quarter. Talos IR observed new variants of Akira and Phobos ransomware for the first time this quarter. Akira Talos IR responded to an Akira ransomware attack for the first time this quarter in an engagement where affiliates deployed the latest ESXi version, “Akira_v2,” as well as a Windows-based variant of Akira named “Megazord.” These new Akira variants are written in the Rust programming language, which is a notable change from the previously used C++ and Crypto++ programming languages.  Talos IR could not determine how initial access was gained, which is common because ransomware attacks often involve multi-stage attack strategies that add additional complexity during the investigation process. Once inside the network, the adversaries began collecting credentials from the memory of the Local Security Authority Subsystem Service (LSASS) and the New Technology Directory Services Directory Information Tree (NTDS.dit) database, where Active Directory data is stored, and leveraged Remote Desktop Protocol (RDP) for lateral movement. Prior to encryption, Megazord ransomware began executing several commands to disable tools and impair defenses, including “net stop” and “taskkill.” Akira_v2 appended the file extension “.akiranew” during encryption, while Megazord ransomware appended the file extension “.powerranges”.   First discovered in early 2023, Akira operates as a ransomware-as-a-service (RaaS) model and employs a double extortion scheme that involves exfiltrating data before encryption. Akira affiliates are known to heavily target small- to medium-sized businesses within several verticals primarily located within the U.S. but have targeted organizations within the U.K., Canada, Iceland, Australia and South Korea. Akira affiliates are notorious for leveraging compromised credentials and exploiting vulnerabilities as a means of gaining initial access, such as the SQL injection vulnerability, tracked as CVE-2021-27876, affecting certain versions of Zoho ManageEngine ADSelfService Plus, and the vulnerability, tracked as CVE-2023-27532, affecting certain versions of Veeam’s Backup & Replication (VBS) software.    Phobos Talos IR has previously observed variants of Phobos ransomware, such as “Faust,” but this quarter, Talos IR responded to an engagement with the “BackMyData” variant of Phobos ransomware. The adversaries leveraged Mimikatz to dump credentials from Active Directory. The adversary also installed several tools in the NirSoft product suite designed to recover passwords, such as PasswordFox and ChromePass, for additional credential enumeration. The adversaries used PsExec to access the domain controller before setting a registry key to permit remote desktop connections. Shortly after, the adversaries also modified the firewall to allow remote desktop connections using the Windows scripting utility, netsh. The remote access tool AnyDesk was downloaded to enable remote access as a means of persistence in the environment. Talos IR assessed with high confidence that Windows Secure Copy (WinSCP) and Secure Shell (SSH) were likely used to exfiltrate staged data. Adversaries also relied on PsExec to execute commands, such as deleting volume shadow copies, as a precursor to deploying the ransomware executable. After encryption, the ransomware appended the file extension “.fastbackdata”.   A notable finding was the persistent use of the “Users/[username]/Music” directory as a staging area for data exfiltration to host malicious scripts, tools and malware, a common technique used by numerous ransomware affiliates to evade detection and remain persistent in the environment. Talos IR also identified a digitally signed executable, “HRSword,” developed by Beijing Huorong Network Technology. It is a tool the affiliate used during the attack for potential secure file deletion and as a defensive measure to disable endpoint protection tools, which Phobos affiliates were previously using, according to public reporting.   Phobos ransomware first emerged in late 2018 and shared many similarities with the Crysis and Dharma ransomware families. Unlike other ransomware families, there are many variants of Phobos ransomware, such as Eking, Eight, Elbie, Devos and Faust. There is little information known about the business model leveraged by the Phobos ransomware operation. In November 2023, Cisco Talos analyzed over a thousand samples of Phobos ransomware to learn more about the affiliate structure and activity, which revealed that Phobos may operate a RaaS model due to the hundreds of contact emails and IDs associated with Phobos campaigns, indicating the malware has a dispersed affiliate base. Talos assessed with moderate confidence that the Phobos ransomware operation is actively managed by a central authority, as there is only one private key capable of decryption in all observed campaigns. Other observed threats  Talos IR responded to an attack where adversaries were attempting to brute force several Cisco Adaptive Security Appliances (ASAs). Although the adversaries were unsuccessful in their attack, this activity is in line with the recently observed trend affecting VPN services. Cisco Talos has recently seen an increase in malicious activity targeting VPN services, web application authentication interfaces, and Secure Shell (SSH) globally. Since at least March 18, Cisco has observed scanning and brute force activity sourcing from The Onion Router (TOR) exit nodes and other anonymous tunnels and proxies. Depending on the target environment, a successful attack could result in unauthorized access to a target network, possibly leading to account lockouts and denial-of-service (DoS) conditions. The brute force attempts include a combination of generic usernames and valid usernames unique to specific organizations. The activity seems indiscriminate and has been observed across multiple industry verticals and geographic regions. Initial vectors The most observed means of gaining initial access was the use of compromised credentials on valid accounts, accounting for 29 percent of engagements, a continuation of a trend from the previous quarter when valid accounts were also a top attack vector. Security weaknesses For the first time, users accepting unauthorized MFA push notifications was the top observed security weakness, accounting for 25 percent of engagements this quarter. The lack of proper MFA implementation closely followed, accounting for 21 percent of engagements, a 44 percent decrease from the previous quarter. Users must have a clear understanding of the appropriate business response protocols when their devices are overwhelmed with an excessive volume of push notifications. Talos IR recommends organizations educate their employees about the specific channels and points of contact for reporting these incidents. Prompt and accurate reporting enables security teams to quickly identify the nature of the issue and implement the necessary measures to address the situation effectively. Organizations should also consider implementing number-matching in MFA applications to provide an additional layer of security to prevent users from accepting malicious MFA push notifications. Talos IR recommends implementing MFA on all critical services including all remote access and identity access management (IAM) services. MFA will be the most effective method for the prevention of remote-based compromises. It also prevents lateral movement by requiring all administrative users to provide a second form of authentication. Organizations can set up alerting for single-factor authentication to quickly identify potential gaps. Top observed MITRE ATT&CK techniques The table below represents the MITRE ATT&CK techniques observed in this quarter’s IR engagements and includes relevant examples and the number of times seen. Given that some techniques can fall under multiple tactics, we grouped them under the most relevant tactic based on the way they were leveraged. Please note, this is not an exhaustive list. Key findings from the MITRE ATT&CK framework include:  

• Remote access software, such as SplashTop and AnyDesk, were used in 17 percent of engagements this quarter, a 20 percent decrease from the previous quarter.  
• The use of email hiding rules was the top observed defense evasion technique, accounting for 21 percent of engagements this quarter.   
• Scheduled tasks were leveraged by adversaries the most this quarter for persistence, accounting for 17 percent of engagements this quarter, a 33 percent increase from the previous quarter.  
• The abuse of remote services, such as RDP, SSH, SMB and WinRM, more than doubled this quarter compared to the previous quarter, accounting for nearly 60 percent of engagements. 

Reconnaissance Example T1589.001 Gather Victim Identity Information: Credentials Adversaries may gather credentials that can be used during their attack.  T1598.003 Phishing for Information: Spearphishing Link Adversaries may send a spearphishing email with a link to a credential harvesting page to collect credentials for their attack. Resource Development Example T1586.002 Compromise Accounts: Email Accounts Adversaries may compromise email accounts that can be used during their attack for malicious activities, such as internal spearphishing. T1583.001 Acquire Infrastructure: Domains Adversaries may acquire domains that can be used for malicious activities, such as hosting malware. T1608.001 Stage Capabilities: Upload Malware Adversaries may upload malware to compromised domains to make it accessible during their attack.  T1583.008 Acquire Infrastructure: Malvertising Adversaries may purchase online advertisements, such as Google ads, that can be used distribute malware to victims. T1608.004 Stage Capabilities: Drive-by Target Adversaries may prepare a website for drive-by compromise by inserting malicious JavaScript.  Initial Access Example T1078 Valid Accounts Adversaries may use compromised credentials to access valid accounts during their attack. T1566 Phishing Adversaries may send phishing messages to gain access to target systems. T1189 Drive-by Compromise Victims may infect their systems with malware over browsing, providing an adversary with access.  T1190 Exploit in Public-Facing Application Adversaries may exploit a vulnerability to gain access to a target system. T1566.002 Phishing: Spearphishing Link Adversaries may send phishing emails with malicious links to lure victims into installing malware.  Execution Example T1059.001 Command and Scripting Interpreter: PowerShell Adversaries may abuse PowerShell to execute commands or scripts throughout their attack. T1059.003 Command and Scripting Interpreter: Windows Command Shell Adversaries may abuse Windows Command Shell to execute commands or scripts throughout their attack. T1569.002 System Services: Service Execution Adversaries may abuse Windows service control manager to execute commands or payloads during their attack. Persistence Example T1053.005 Scheduled Task / Job: Scheduled Task Adversaries may abuse the Windows Task Scheduler to perform task scheduling for recurring execution of malware or malicious commands. T1574.002 Hijack Execution: DLL Side-Loading Adversaries may execute their own malicious code by side-loading DLL files into legitimate programs.  Privilege Escalation Example T1548.002 Abuse Elevation Control Mechanism: Bypass User Account Control Adversaries may bypass UAC mechanisms to elevate their permissions on a system. Defense Evasion Example T1564.008 Hide Artifacts: Email Hiding Rules Adversaries may create inbox rules to forward certain incoming emails to a folder to hide them from the inbox owner. T1070.004 Indicator Removal: File Deletion Adversaries may delete files to cover their tracks during the attack.  T1218.011 System Signed Binary Proxy Execution: Rundll32 Adversaries may abuse the Windows utility rundll32.exe to execute malware.  T1112 Modify Registry Adversaries may modify the registry to maintain persistence on a target system.  T1562.010 Impair Defenses: Downgrade Attack Adversaries may downgrade a program, such as PowerShell, to a version that is vulnerable to exploits. Credential Access Example T1621 Multi-Factor Authentication Request Generation Adversaries may generate MFA push notifications causing an MFA exhaustion attack. T1003.005 OS Credential Dumping: NTDS Adversaries may dump the contents of the NTDS.dit file to access credentials that can be used for lateral movement. T1003.001 OS Credential Dumping: LSASS Adversaries may dump the contents of LSASS to access credentials that can be used for lateral movement T1003.002 OS Credential Dumping: Service Account Manager Adversaries may dump the contents of the service account manager to access credentials that can be used for lateral movement. T1110.002 Brute Force: Password Cracking Adversaries may use brute force account passwords to compromise accounts. Discovery Example T1069.001 Permission Groups Discovery: Local Groups Adversaries may attempt to discover local permissions groups with commands, such as “net localgroup.”  T1069.002 Permission Groups Discovery: Domain Groups Adversaries may attempt to discover domain groups with commands, such as “net group /domain.” T1201 Password Policy Discovery Adversaries may attempt to discover information about the password policy within a compromised network with commands, such as “net accounts.” Lateral Movement Example T1021.001 Remote Services: Remote Desktop Protocol Adversaries may abuse valid accounts using RDP to move laterally in a target environment.  T1534 Internal Spearphishing Adversaries may abuse a compromised email account to send internal spearphishing emails to move laterally. T1021.002 Remote Services: SMB / Windows Admin Shares Adversaries may abuse valid accounts using SMB to move laterally in a target environment. T1021.004 Remote Services: SSH Adversaries may abuse valid accounts using SSH to move laterally in a target environment. T1021.001 Remote Services: Windows Remote Management Adversaries may abuse valid accounts using WinRM to move laterally in a target environment. Collection Example T1114.002 Email Collection: Remote Email Collection Adversaries may target a Microsoft Exchange server to collect information.  T1074.001 Data Staged: Local Data Staging Adversaries may stage collected data in preparation for exfiltration. T1074 Data Staged Adversaries may stage collected data in preparation for exfiltration. Command and Control Example T1105 Ingress Tool Transfer Adversaries may transfer tools from an external system to a compromised system. T1219 Remote Access Software  Adversaries may abuse remote access software, such as AnyDesk, to establish an interactive C2 channel during their attack.  Exfiltration Example T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage Adversaries may exfiltrate data to a cloud storage provider, such as Dropbox.  Impact Example T1486 Data Encrypted for Impact Adversaries may use ransomware to encrypt data on a target system.  T1490 Inhibit System Recovery Adversaries may disable system recovery features, such as volume shadow copies.  T1657 Financial Theft Adversaries may commit financial fraud during the attack. 

Ya hemos cargado los primeros lotes de 100 Tempos para los casi 1.000 registrados a la RootedCON 2024 dentro de MyPublicInbox, así que si estás entre ellos, recibirás (o habrás recibido ya), los Tempos  de MyPublicInbox, y la entrada de OpenExpo Europe 2024, que te entregan por haber asistido a esta edición de la CON más grande de España.
Figura 1: RootedCON 2024 - Tus Tempos de MyPublicInboxy tus entradas para OpenExpo Europe 2024
Para recibirlos no tienes más que tener cuenta en MyPublicInbox, con el mismo correo electrónico con el que te registraste en RootedCON 2024. La plataforma te cargará 100 Tempos si la cuenta la tienes ya creada, y si no, cuando la crees, los recibirás. Y lo mismo pasará con tu entrada para OpenExpo Europe 2024.
Figura 2: El mensaje de Leire avisando a Román Ramírez queha recibido sus 100 Tempos por asistir a la RootedCON 2024.
Si no tienes cuenta en MyPublicInbox, pero te la sacas con el mismo correo electrónico con el que te registraste, entonces verás que nada más crear la cuenta se te cargarán los 100 Tempos. Y de igual manera con tu entrada para OpenExpo Europe 2024.
Figura 3: OpenExpo Europe 2024: The Power of GenAI.Recibirás también tu entrada vía MyPublicInbox.
El sistema que utilizamos es un cruzado de hashes no reversibles, para garantizar la privacidad de los datos, donde se comparan hashes, y cuando hay "match", se asignan Tempos y entradas de OpenExpo Europe 2024.
Figura 4: RootedCON 2024 Portugal
Además, tengo que dejaros info de la próxima RootedCON 2024 Portugal, que va a tener lugar en el mes de Mayo, así que si quieres continuar con la experiencia de la CON en el país vecino, te puedes organizar unos días disfrutando del buen clima, el hacking, y el buen comer en Portugal.
¡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

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 ︎

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

I've been working on comparing data from different DShield [1] honeypots to understand differences when the honeypots reside on different networks. One point of comparison is malware submitted to the honeypots. During a review of the summarized data, I noticed that one honeypot was an outlier in terms of malware captured. 
 
Figure 1: Highlighted differences for one honeypot and malware uploaded or downloaded to it.    A honeypot in Azure [2] had only seen two files:

• a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2 [3]
• 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b [4]

In addition, there were four files seen for all the honeypots except for the Azure honeypot:

• 7a9da7d10aa80b0f9e2e3f9e518030c86026a636e0b6de35905e15dd4c8e3e2d [5]
• 199d11d0fd7043fe9206954ed8bc7b54d1912013a2a71bdf8bb007b71bb490c8 [6]
• 18e0f574bf11bc5e7de8c95b83c187649b2d87d74651e59d9c2aad53ac7bb7f1 [7]
• f344f455f7c90b835c2a8e87d5e6a2c1f8f5c02324a8e02bd066c3a10be1f3d0 [8]

Another unusual item was the reported network ports showing activity. 
Figure 2: Highlighted ports for Azure honeypot, demonstrating gaps in port activity reported by other honeypots.   Looking into the logs, I noticed that the local firewall logs were not updated since January 2024. Outside of filtering traffic to the normal administrative SSH port (%%port:12222%%), the iptables firewall also provides NAT redirected ports to add surface area to the honeypot.   
Figure 3: Highlighted ports only made available due to iptables NAT redirection rules (%%port:22%%, %%port:23%%, %%port:2323%%, %%port:80%%, %%port:8080%%, %%port:7547%%, %%port:5555%%, %%port:9000%%)  
Figure 4: Example iptables rules for honeypot, highlighting NAT rules   This required setting up another honeypot to make sure similar data was being collected. Since I recalled having some issues setting up the Azure honeypot originally, I decided to use a different operating system. The honeypot was originally set up with Linux (ubuntu 20.04). After trying Linux (debian 11), I had issues with iptables being properly configured after a completed install as well. When using Linux (debian 12), the installation of the honeypot completed and iptables rules were configured correctly. So, did the change in attack surface change the malware found on the new honeypot?  
Figure 5: New malware highlighted that was submitted to an Azure honeypot with functioning iptables that contained proper NAT redirection rules.   It does appear that the change in ports did impact data received. It only took a few days of waiting. The firewall logs of the new Azure honeypot showed only activity fo TCP port 22 for the IP address registered for the cowrie [10] session, which without iptables would have not been available for attack.   honeypotuser@azurehp2:/logs$ zcat /var/log/dshield.log*.gz | grep "49.87.111.198" | awk '{print $18}' DPT=22 DPT=22 DPT=22 DPT=22 DPT=22   Having iptables properly configured can help protect the administrative port, but will also impact data received. The changed attack surface in my case meant not seeing some attacks that may only be looking for SSH over TCP port 22. Having iptables functioning properly also means having firewall log data to analyze.    [1] https://isc.sans.edu/honeypot.html
[2] https://azure.microsoft.com/
[3] https://www.virustotal.com/gui/file/a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
[4] https://www.virustotal.com/gui/file/01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
[5] https://www.virustotal.com/gui/file/7a9da7d10aa80b0f9e2e3f9e518030c86026a636e0b6de35905e15dd4c8e3e2d
[6] https://www.virustotal.com/gui/file/199d11d0fd7043fe9206954ed8bc7b54d1912013a2a71bdf8bb007b71bb490c8
[7] https://www.virustotal.com/gui/file/18e0f574bf11bc5e7de8c95b83c187649b2d87d74651e59d9c2aad53ac7bb7f1
[8] https://www.virustotal.com/gui/file/f344f455f7c90b835c2a8e87d5e6a2c1f8f5c02324a8e02bd066c3a10be1f3d0
[9] https://www.virustotal.com/gui/file/3c5ffe548ea93622d11b67eead48d50f9ee39b09e1e813747883d1528569ffd1
[10] https://github.com/cowrie/cowrie --
Jesse La Grew
Handler (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Enlarge (credit: Getty Images) Hackers backed by a powerful nation-state have been exploiting two zero-day vulnerabilities in Cisco firewalls in a five-month-long campaign that breaks into government networks around the world, researchers reported Wednesday. The attacks against Cisco’s Adaptive Security Appliances firewalls are the latest in a rash of network compromises that target firewalls, VPNs, and network-perimeter devices, which are designed to provide a moated gate of sorts that keeps remote hackers out. Over the past 18 months, threat actors—mainly backed by the Chinese government—have turned this security paradigm on its head in attacks that exploit previously unknown vulnerabilities in security appliances from the likes of Ivanti, Atlassian, Citrix, and Progress. These devices are ideal targets because they sit at the edge of a network, provide a direct pipeline to its most sensitive resources, and interact with virtually all incoming communications. Cisco ASA likely one of several targets On Wednesday, it was Cisco’s turn to warn that its ASA products have received such treatment. Since November, a previously unknown actor tracked as UAT4356 by Cisco and STORM-1849 by Microsoft has been exploiting two zero-days in attacks that go on to install two pieces of never-before-seen malware, researchers with Cisco’s Talos security team said. Notable traits in the attacks include:Read 12 remaining paragraphs | Comments

Enlarge (credit: Getty Images) On Friday, a federal judicial panel convened in Washington, DC, to discuss the challenges of policing AI-generated evidence in court trials, according to a Reuters report. The US Judicial Conference's Advisory Committee on Evidence Rules, an eight-member panel responsible for drafting evidence-related amendments to the Federal Rules of Evidence, heard from computer scientists and academics about the potential risks of AI being used to manipulate images and videos or create deepfakes that could disrupt a trial. The meeting took place amid broader efforts by federal and state courts nationwide to address the rise of generative AI models (such as those that power OpenAI's ChatGPT or Stability AI's Stable Diffusion), which can be trained on large datasets with the aim of producing realistic text, images, audio, or videos. In the published 358-page agenda for the meeting, the committee offers up this definition of a deepfake and the problems AI-generated media may pose in legal trials:Read 9 remaining paragraphs | Comments

ArcaneDoor is a campaign that is the latest example of state-sponsored actors targeting perimeter network devices from multiple vendors. Coveted by these actors, perimeter network devices are the perfect intrusion point for espionage-focused campaigns. As a critical path for data into and out of the network, these devices need to be routinely and promptly patched; using up-to-date hardware and software versions and configurations; and be closely monitored from a security perspective. Gaining a foothold on these devices allows an actor to directly pivot into an organization, reroute or modify traffic and monitor network communications. In the past two years, we have seen a dramatic and sustained increase in the targeting of these devices in areas such as telecommunications providers and energy sector organizations — critical infrastructure entities that are likely strategic targets of interest for many foreign governments.  Cisco’s position as a leading global network infrastructure vendor gives Talos’ Intelligence and Interdiction team immense visibility into the general state of network hygiene. This also gives us uniquely positioned investigative capability into attacks of this nature. Early in 2024, a vigilant customer reached out to both Cisco’s Product Security Incident Response Team (PSIRT) and Cisco Talos to discuss security concerns with their Cisco Adaptive Security Appliances (ASA). PSIRT and Talos came together to launch an investigation to assist the customer. During that investigation, which eventually included several external intelligence partners and spanned several months, we identified a previously unknown actor now tracked as UAT4356 by Talos and STORM-1849 by the Microsoft Threat Intelligence Center. This actor utilized bespoke tooling that demonstrated a clear focus on espionage and an in-depth knowledge of the devices that they targeted, hallmarks of a sophisticated state-sponsored actor. UAT4356 deployed two backdoors as components of this campaign, “Line Runner” and “Line Dancer,” which were used collectively to conduct malicious actions on-target, which included configuration modification, reconnaissance, network traffic capture/exfiltration and potentially lateral movement.  Critical Fixes Available Working with victims and intelligence partners, Cisco uncovered a sophisticated attack chain that was used to implant custom malware and execute commands across a small set of customers. While we have been unable to identify the initial attack vector, we have identified two vulnerabilities (CVE-2024-20353 and CVE-2024-20359), which we detail below. Customers are strongly advised to follow the guidance published in the security advisories discussed below.  Further, network telemetry and information from intelligence partners indicate the actor is interested in — and potentially attacking — network devices from Microsoft and other vendors. Regardless of your network equipment provider, now is the time to ensure that the devices are properly patched, logging to a central, secure location, and configured to have strong, multi-factor authentication (MFA). Additional recommendations specific to Cisco are available here.  Timeline Cisco was initially alerted to suspicious activity on an ASA device in early 2024. The investigation that followed identified additional victims, all of which involved government networks globally. During the investigation, we identified actor-controlled infrastructure dating back to early November 2023, with most activity taking place between December 2023 and early January 2024. Further, we have identified evidence that suggests this capability was being tested and developed as early as July 2023.   Cisco has identified two vulnerabilities that were abused in this campaign (CVE-2024-20353 and CVE-2024-20359). Patches for these vulnerabilities are detailed in the Cisco Security Advisories released today.Initial Access We have not determined the initial access vector used in this campaign. We have not identified evidence of pre-authentication exploitation to date. Our investigation is ongoing, and we will provide updates, if necessary, in the security advisories or on this blog.Line Dancer: In-Memory Implant Technical Details The malware implant has a couple of key components. The first is a memory-only implant, called “Line Dancer.” This implant is a memory-resident shellcode interpreter that enables adversaries to upload and execute arbitrary shellcode payloads.  On a compromised ASA, the attackers submit shellcode via the host-scan-reply field, which is then parsed by the Line Dancer implant. Note that the use of this field does not indicate the exploitation of CVE-2018-0101 which was NOT used as a component of this campaign. The host-scan-reply field, typically used in later parts of the SSL VPN session establishment process, is processed by ASA devices configured for SSL VPN, IPsec IKEv2 VPN with “client-services" or HTTPS management access. The actor overrides the pointer to the default host-scan-reply code to instead point to the Line Dancer shellcode interpreter. This allows the actor to use POST requests to interact with the device without having to authenticate and interact directly through any traditional management interfaces. Line Dancer is used to execute commands on the compromised device. During our investigation, Talos was able to observe the threat actors using the Line Dancer malware implant to: 

• Disable syslog. 
• Run and exfiltrate the command show configuration. 
• Create and exfiltrate packet captures. 
• Execute CLI commands present in shellcode; this includes configuration mode commands and the ability to save them to memory (write mem). 
• Hook the crash dump process, which forces the device to skip the crash dump generation and jump directly to a device reboot. This is designed to evade forensic analysis, as the crash dump would contain evidence of compromise and provide additional forensic details to investigators. 
• Hook the AAA (Authentication, Authorization and Accounting) function to allow for a magic number authentication capability. When the attacker attempts to connect to the device using this magic number, they are able to establish a remote access VPN tunnel bypassing the configured AAA mechanisms. As an alternate form of access, a P12 blob is generated along with an associated certificate and exfiltrated to the actor along with a certificate-based tunnel configuration.  

Host-Scan-Reply hook overview In the Line Dancer implant’s process memory, we found a function (detailed below) that checks if a 32-byte token matches a pattern. If so, it base64-decodes the payload, copies it into the attacker's writable and executable memory region, and then calls the newly decoded function. Either way, it ends by calling processHostScanReply(). 

The function processHostScanReply() is normally accessed through a function pointer in the elementArray table, associated with the string host-scan-reply. In the captured memory, the entry that should point to processHostScanReply() now instead points to the attacker's function that decodes and runs its payload. Since this change is in the data section of memory, it doesn't show up in hashes/dumps of text. 
 
The attacker function that decodes and runs its payload has the following decompilation: Line Runner: Persistence Mechanism The threat actor maintains persistence utilizing a second, but persistent, backdoor called “Line Runner” on the compromised ASA device using functionality related to a legacy capability that allowed for the pre-loading of VPN clients and plugins on the device. At boot, the ASA is designed to look for the presence of a file on disk0: matching the Lua regular expression: ^client_bundle[%w_-]*%.zip$  If the file exists, it will unzip it and execute the script csco_config.lua. Once processed, the ZIP file is deleted. This is assigned CVE-2024-20359 and more details are available in this Cisco Security Advisory.  In at least one case, there is another vulnerability, CVE-2024-20353, that was abused by the actor to facilitate this process. The attackers were able to leverage this vulnerability to cause the target ASA device to reboot, triggering the unzipping and installing the second component of the threat actor’s malware implant, Line Runner. The threat actor’s ZIP file has the following files: The scripts in the zip file allow the threat actor to maintain a persistent HTTP-based Lua backdoor to the ASA, which survives across reboots and upgrades. Line Runner was observed being used by UAT4356 to retrieve information that was staged through the use of Line Dancer.  csco_config.lua The csco_config.lua file is run at boot and makes the following modifications to the system: 
 
• Create disk0:/csco_config/97/webcontent/ if it doesn't already exist 
• Create disk0:/csco_config/97/webcontent/1515480F4B538B669648B17C02337098 from hash.txt 
• Append index.txt to disk0:/csco_config/97/webcontent/index_bp.ini and put the result in disk0:/csco_config/97/webcontent/index.ini 
• Move the original client_bundle.zip file to /run/lock/subsys/krbkdc6
• Prepend umtfc.txt to /etc/init.d/umountfs 
• Copy stgvdr.txt to /asa/scripts/lina_cs 
• Backup /asa/scripts/lina_exe_cs.sh to /asa/scripts/lina_exe_cs_bp.sh 
• Replace /asa/scripts/lina_exe_cs.sh with laecsnw.txt 
• Copy csco_config2.lua over csco_config.lua 
• Disable the importPlugin function for the next call only  csco_config2.lua The csco_config2.lua file cleans up the modifications made by csco_config.lua (above) and removes itself. hash.txt Used as content for disk0:/csco_config/97/webcontent/1515480F4B538B669648B17C02337098. Intercepts HTTP requests to the ASA. The threat actor’s code looks for an HTTP request with a set of 32-character parameters that are victim-dependent. If they match, then the payload contained within one of these parameters is written to a Lua script and executed. This is the backdoor’s command and control mechanism. index.txt Adds webContent information so hash.txt is processed. laecsnw.txt Temporarily replaces /asa/scripts/lina_exe_cs.sh. Executes /asa/scripts/lina_cs as a background process (see below). Removes itself. Then restore the backup /asa/scripts/lina_exe_cs_bp.sh.  stgvdr.txt Runs as /asa/scripts/lina_cs. After sleeping for 30 seconds, sets expected owner and times on /etc/init.d/umountfs. Removes the hash API endpoint, the index.ini, and either restores the backup index.ini or removes the webcontent directory entirely. Finally, removes itself.  umtfc.txtPrepended to /etc/init.d/unmountfs. The unmountfs script is called at shutdown to unmount the filesystems. The threat actor’s modifications perform the following functionality: • If disk0:/csco_config/97/webcontent/1515480F4B538B669648B17C02337098 exists, it removes it and index.ini. 
• Copy /run/lock/subsys/krbkdc6 to disk0:client_bundle_install.zipThis sets up the zipfile to be executed at the next boot, maintaining persistence. Forensic Recovery and Identification of Line Runner To identify the presence of Line Runner on an ASA, the following methods can be used. Note also that the device should be upgraded to a fixed version as identified in the first method. Method 1: After updating the device to a software release that contains the fix for CVE-2024-20359, a review of the contents of disk0: should be conducted. If a new file (e.g., “client_bundle_install.zip” or any other unusual .zip file) appears on disk0: following the update, this suggests that Line Runner was present on the device in question. Note that because the updated software is not vulnerable to CVE-2024-20359, Line Runner will no longer be active on the device. Method 2: To detect (and remove) Line Runner, the following series of commands will create an innocuous file with a .zip extension. Note that it will not create a valid zip file, but the file will still be read by the ASA at reboot. Upon execution of the following commands, if a new .zip file appears on disk0: following the reload, this suggests that Line Runner was present on the device in question. Deletion of the “client_bundle_install.zip” file will remove Line Runner. Note that the malicious ZIP containing the Line Runner functionality could have other names that fit the naming pattern outlined previously.  If you discover a newly created .zip file, copy that file off the device using the copy command and contact psirt@cisco.com referencing CVE-2024-20359. Include the outputs of the dir disk0: and show version commands from the device and the .zip file extracted from the device. Anti-Forensics/Anti-Analysis Capabilities UAT4356 took clear and deliberate steps to attempt to prevent forensic capture of malicious artifacts. This tradecraft suggests a thorough understanding of the ASA itself and of the forensic actions commonly performed by Cisco for network device integrity validation. Additional steps were taken on a case-by-case basis to hide actions being taken on the device. These steps included hooking the AAA (Authentication, Authorization and Accounting) function of the device to allow the actor to bypass normal AAA operations. We also identified some instances where UAT4356 disabled logging to perform operations on or from the ASA and not have those operations or actions logged.  Line Dancer appears to have been intentionally placed into a difficult-to-reach region of memory. In addition, it hooks into functions such as the core dump function, which is commonly used to collect information for debugging and forensic purposes, which were made in memory such that this function simply jumped to a reboot. This means that on reboot, Line Dancer itself would no longer be present and none of the collections present in the core dump function would have been executed, all resulting in a complete loss of debug information and memory-based forensic artifacts. Attribution  As a part of our ongoing investigation, we have also conducted analysis on possible attribution of this activity. Our attribution assessment is based on the victimology, the significant level of tradecraft employed in terms of capability development and anti-forensic measures, and the identification and subsequent chaining together of 0-day vulnerabilities. For these reasons, we assess with high confidence that these actions were performed by a state-sponsored actor.Recommendations There are some known indicators of compromise that customers can look for if they suspect they may have been targeted in this campaign. First, organizations should look for any flows to/from ASA devices to any of the IP addresses present in the IOC list provided at the bottom of this blog. This is one indication that further investigation is necessary. Additionally, organizations can issue the command show memory region | include lina to identify another indicator of compromise. If the output indicates more than one executable memory region (memory regions having r-xp permissions, see output examples), especially if one of these memory sections is exactly 0x1000 bytes, then this is a sign of potential tampering.   Output of the ‘show memory region’ command for a compromised device (top) vs. a clean device (bottom).Note that the earlier provided steps to identify the presence of Line Runner can still be followed even in the absence of more than one executable memory region as we have seen cases where Line Runner was present without Line Dancer being present. We still recommend following the steps to upgrade to a patched version even if customers believe that their device has not been compromised.  Next, follow the steps detailed in the Cisco ASA Forensic Investigation Procedures for First Responders. When following these procedures first responders should NOT attempt to collect a core dump (Step 5) or reboot the device if they believe that the device has been compromised, based on the lina memory region output. The previous steps up to and including a collection of the memory text section should be followed. In addition, we have released some Snort signatures to detect the activity on the wire including access attempts. Signatures 63139, 62949, and 45575 have been released to detect the implants or associated behaviors. Please note that the device must be set up to decrypt TLS for these signatures to be effective. 

• CVE-2024-20353 (ASA DOS/Reboot) - 3:63139 
• ‘Line Runner’ – Persistence Mechanism Interaction – 3:62949 
• ‘Line Dancer’ – In-Memory Only Shellcode Interpreter Interaction – 3:45575 
• Note that this signature was originally built to detect an unrelated CVE but it also detects Line Dancer interaction 

If your organization does find connections to the provided actor IPs and the crash dump functionality has been altered, please open a case with Cisco TAC.  UAT4356 Infrastructure Key components of the actor-controlled infrastructure used for this operation had an interesting overlap of SSL certificates which match the below pattern while also appearing as an ASA, during the same period, to external scanning engines such as Shodan and Censys as reported by the CPE data on the same port as the noted SSL certificate. The SSL certificate information suggests that the infrastructure is making use of an OpenConnect VPN Server (https://ocserv.openconnect-vpn.net) through which the actor appeared to be conducting actions on target. Certificate Pattern: 
:issuer = O=ocserv,CN=ocserv VPN 
:selfsigned = true 
:serial = 0000000000000000000000000000000000000002 
:subject = O=ocserv,CN=ocserv VPN 
:version = v3 CPE identifiers:  
cpe:2.3:a:cisco:http:*:*:*:*:*:*::
cpe:2.3:h:cisco:adaptive_security_appliance:*:*:*:*:*:*:*:* 
cpe:2.3:o:cisco:adaptive_security_appliance_software:*:*:*:*:*:*:*:* MITRE TTPs This  threat demonstrates several techniques of the MITRE ATT&CK framework, most notably: 

• Line Runner persistence mechanism (T1037),  
• The reboot action via CVE-2024-20353 (T1653),  
• Base64 obfuscation (T1140),  
• Hooking of the processHostScanReply() function (T0874),  
• Disabling syslog and tampering with AAA (T1562-001), 
• Injection of code into AAA and Crash Dump processes (T1055)  
• Execution of CLI commands (T1059),  
• Bypassing of the AAA mechanism (T1556),  
• Removal of files after execution (T1070-004),  
• HTTP interception for C2 communications (T1557),  
• HTTP C2 (T1071-001),  
• HTTP C2 one-way backdoor (T1102-003),  
• Data exfiltration over C2 (T1041),  
• Network sniffing (T1040)  

Coverage Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat. Umbrella, Cisco's secure internet gateway (SIG) blocks devices from connecting to malicious IPs. Sign up for a free trial of Umbrella here. Additional protections with context to your specific environment and threat data are available from the Firewall Management Center. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. Snort SIDs for this threat are 45575, 62949 and 63139. Indicators of Compromise (IOCs)  There are several known indicators of compromise that defenders can look for when assessing whether their ASA device has been compromised as a result of this attack, as outlined earlier in this post. For example, if any gaps in logging or any recent unexpected reboots are observed, this should be treated as suspicious activity that warrants further investigation. Also, below is a list of IP addresses we identified as having been used by UAT4356. Please note that some of these IPs are part of publicly known anonymization infrastructure and not directly controlled by the attackers themselves. If your organization does find connections to the provided actor IPs and the crash dump functionality has been altered, please open a case with Cisco TAC. Likely Actor-Controlled Infrastructure: 192.36.57[.]181 
185.167.60[.]85 
185.227.111[.]17 
176.31.18[.]153 
172.105.90[.]154 
185.244.210[.]120 
45.86.163[.]224 
172.105.94[.]93 
213.156.138[.]77 
89.44.198[.]189 
45.77.52[.]253 
103.114.200[.]230 
212.193.2[.]48 
51.15.145[.]37 
89.44.198[.]196 
131.196.252[.]148 
213.156.138[.]78 
121.227.168[.]69 
213.156.138[.]68 
194.4.49[.]6 
185.244.210[.]65 
216.238.75[.]155  Multi-Tenant Infrastructure: 5.183.95[.]95 
45.63.119[.]131 
45.76.118[.]87 
45.77.54[.]14 
45.86.163[.]244 
45.128.134[.]189    
89.44.198[.]16 
96.44.159[.]46 
103.20.222[.]218 
103.27.132[.]69 
103.51.140[.]101 
103.119.3[.]230 
103.125.218[.]198 
104.156.232[.]22 
107.148.19[.]88 
107.172.16[.]208 
107.173.140[.]111 
121.37.174[.]139 
139.162.135[.]12 
149.28.166[.]244 
152.70.83[.]47 
154.22.235[.]13 
154.22.235[.]17 
154.39.142[.]47  
172.233.245[.]241 
185.123.101[.]250 
192.210.137[.]35  
194.32.78[.]183 
205.234.232[.]196  
207.148.74[.]250 
216.155.157[.]136 
216.238.66[.]251 
216.238.71[.]49 
216.238.72[.]201 
216.238.74[.]95 
216.238.81[.]149 
216.238.85[.]220 
216.238.86[.]24  Acknowledgments  Cisco would like to thank the following organizations for supporting this investigation: 

• Australian Signals Directorate’s Australian Cyber Security Centre 
• Black Lotus Labs at Lumen Technologies 
• Canadian Centre for Cyber Security, a part of the Communications Security Establishment 
• Microsoft Threat Intelligence Center 
• The UK's National Cyber Security Centre (NCSC) 
• U.S. Cybersecurity & Infrastructure Security Agency (CISA) 

Phishing threats have reached unprecedented levels of sophistication in the past year, driven by the proliferation of generative AI tools. Transforming how cybercriminals operate, AI advancements are revolutionizing and reshaping the phishing threat landscape. Moreover, this technology has democratized the ability to orchestrate intricate phishing campaigns, making it easier than ever for even beginners to conduct complex and believable phishing attacks. Specifically, this observed shift is enabling novice cybercriminals to launch highly convincing, personalized scams with ease. As a result, organizations now face a myriad of new challenges in protecting their data and systems from the increasing onslaught of phishing attacks. In response, the Zscaler ThreatLabz team has released the 2024 Phishing Report. This report analyzes over 2 billion phishing transactions from 2023, found within the Zscaler cloud, to equip organizations with a clear understanding of the rapidly evolving phishing landscape. Providing insights into the latest trends and tactics used by cybercriminals, the report highlights active phishing campaigns, exposes emerging schemes, and identifies top targets by region, industry, imitated brand, and more. Showcasing real-world examples, ThreatLabz phishing findings underscore the importance of applying constant vigilance and zero trust security strategies. The guidance offered aims to help organizations strengthen their defenses against these evolving phishing techniques.Download the Zscaler ThreatLabz 2024 Phishing Report to gain the knowledge needed to proactively combat the rising wave of new phishing threats. 6 key phishing findingsThe following findings represent a subset of key phishing trend discoveries that shed light on the evolution of phishing tactics. Top phishing trends Phishing attacks surged by 58.2% in 2023 compared to the previous year, reflecting the growing sophistication and reach of threat actors. Voice phishing (vishing) and deepfake phishing attacks are on the rise as attackers harness generative AI tools to amplify their social engineering tactics. Adversary-in-the-middle (AiTM) phishing attacks persist and browser-in-the-browser (BiTB) attacks are emerging as a growing threat. Top phishing targets The US, UK, India, Canada, and Germany were the top five countries targeted by phishing attacks. The finance and insurance industry faced 27.8% of overall phishing attacks, marking the highest concentration among industries and a 393% year-over-year increase. Microsoft remains the most frequently imitated brand, with 43.1% of phishing attempts targeting it. Discover further insights into each of these findings and more in the report. Spotlight on AI-enabled phishing threatsGenAI has undoubtedly proven transformative in turning up productivity across businesses. Yet on the flip side of this transformation is a perilous truth: AI is also turning novice to average threat actors into skilled social engineers and sophisticated phishing attackers.By automating and personalizing various components of the attack process, AI speeds up and refines phishing attacks, making them more sophisticated and difficult to detect. GenAI quickly analyzes public data, such as information about organizations and executives, saving time in reconnaissance for threat actors and enabling more precise targeted attacks. LLM chatbots craft accurate, believable phishing communications and emails by eliminating misspellings and grammar mistakes. GenAI can swiftly generate convincing phishing pages. The ThreatLabz report showcases how ChatGPT created a phishing login page in less than 10 prompts, and provides key indicators to look out for when identifying a phishing page. AI has blurred the line between authentic and fraudulent content, making it all the more challenging to discern phishing schemes from legitimate web pages and digital communication.As ThreatLabz researchers tracked phishing trends throughout 2023, several notable advanced AI tactics also emerged. Among these were the rise of vishing and deepfake phishing, increasingly favored social engineering tactics that use AI-powered impersonation tools. Vishing insightsAdvanced vishing campaigns are gaining popularity globally, leading to substantial financial losses in some cases. In a notable attempt that ThreatLabz thwarted during the summer of 2023, phishing attackers used AI technology to perpetrate a vishing attack by impersonating Zscaler CEO Jay Chaudhry. The report details the sequence of events, serving as a critical reminder for enterprises and employees to stay vigilant against vishing scammers. ThreatLabz anticipates a continued surge in targeted voice phishing campaigns led by groups like Scattered Spider in the next year. As these efforts aim to acquire employee login credentials, it is imperative for organizations to fortify their phishing defenses to prevent unauthorized access and exploitation. Deepfake insightsPhishing attacks involving deepfakes will be one of the most challenging AI-driven cyberthreats. Threat actors now possess the ability to create video content that precisely and accurately replicates faces, voices, and mannerisms. This manipulation has already manifested in concerning ways, such as in the electoral process, where deepfake videos fabricate false narratives or statements from political figures. These videos can sway public opinion, disseminate disinformation, and erode trust in the integrity of the electoral process. As society becomes more and more reliant on digital communication and media consumption, the potential political and life-altering ramifications of deepfake scams will likely extend far beyond the scope of current applications. From financial scams to corporate espionage, the use of deepfake technology poses a significant threat to organizations, individuals, and society at large.Additionally, ThreatLabz observed a rise in QR code scams, recruitment scams, browser-in-the-browser (BitB) attacks, and adversary-in-the-middle (AiTM) attacks. Learn more about each of these schemes in the report. Mitigate phishing risk with zero trustGiven the concerning threat landscape uncovered by this year’s report, how can organizations protect against the latest phishing threats? One definitive solution lies in establishing a foundation of a zero trust architecture. Adapting security strategies to combat new phishing trends and mitigate associated risks is crucial—and zero trust is a proven strategy.The Zscaler ThreatLabz 2024 Phishing Report provides essential guidance to this end, including: Fighting AI with AI: Learn about Zscaler’s AI-powered phishing prevention capabilities needed to combat AI-driven threats, including preventing browser exploitation from phishing pages with Zscaler Browser Isolation Zero trust architecture advantages: Learn how the Zscaler Zero Trust Exchange prevents traditional and AI-driven phishing at multiple stages of the attack chain: Prevent compromise: TLS/SSL inspection at scale, AI-powered browser isolation and policy-driven access controls prevent access to suspicious websites. Eliminate lateral movement: Users connect directly to applications, not the network, while AI-powered app segmentation limits the blast radius of a potential incident. Shut down compromised users and insider threats: Inline inspection prevents private application exploit attempts, and integrated deception capabilities detect the most sophisticated attackers. Stop data loss: Inspection of data in-motion and at-rest prevents potential theft by an active attacker. Foundational security best practices: Learn fundamental security best practices to enhance overall resilience to phishing attacks. Download your copy of the Zscaler ThreatLabz 2024 Phishing Report today. Phishing attacks will persist and remain a pervasive threat to organizations. By understanding the latest phishing trends, assessing the associated risks, and recognizing the implications of AI-driven attacks, your organization will be better equipped to defend against phishing in 2024 and beyond.

By Max Ammann This blog showcases five examples of real-world vulnerabilities that we’ve disclosed in the past year (but have not publicly disclosed before). We also share the frustrations we faced in disclosing them to illustrate the need for effective disclosure processes. Here are the five bugs:

• Undefined behavior in the borsh-rs Rust library
• Denial-of-service (DoS) vector in Rust libraries for parsing the Ethereum ABI
• Missing limit on authentication tag length in Expo
• DoS vector in the num-bigint Rust library
• Insertion of MMKV database encryption key into Android system log with react-native-mmkv

Discovering a vulnerability in an open-source project necessitates a careful approach, as publicly reporting it (also known as full disclosure) can alert attackers before a fix is ready. Coordinated vulnerability disclosure (CVD) uses a safer, structured reporting framework to minimize risks. Our five example cases demonstrate how the lack of a CVD process unnecessarily complicated reporting these bugs and ensuring their remediation in a timely manner. In the Takeaways section, we show you how to set up your project for success by providing a basic security policy you can use and walking you through a streamlined disclosure process called GitHub private reporting. GitHub’s feature has several benefits:

• Discreet and secure alerts to developers: no need for PGP-encrypted emails
• Streamlined process: no playing hide-and-seek with company email addresses
• Simple CVE issuance: no need to file a CVE form at MITRE

Time for action: If you own well-known projects on GitHub, use private reporting today! Read more on Configuring private vulnerability reporting for a repository, or skip to the Takeaways section of this post. Case 1: Undefined behavior in borsh-rs Rust library The first case, and reason for implementing a thorough security policy, concerned a bug in a cryptographic serialization library called borsh-rs that was not fixed for two years. During an audit, I discovered unsafe Rust code that could cause undefined behavior if used with zero-sized types that don’t implement the Copy trait. Even though somebody else reported this bug previously, it was left unfixed because it was unclear to the developers how to avoid the undefined behavior in the code and keep the same properties (e.g., resistance against a DoS attack). During that time, the library’s users were not informed about the bug. The whole process could have been streamlined using GitHub’s private reporting feature. If project developers cannot address a vulnerability when it is reported privately, they can still notify Dependabot users about it with a single click. Releasing an actual fix is optional when reporting vulnerabilities privately on GitHub. I reached out to the borsh-rs developers about notifying users while there was no fix available. The developers decided that it was best to notify users because only certain uses of the library caused undefined behavior. We filed the notification RUSTSEC-2023-0033, which created a GitHub advisory. A few months later, the developers fixed the bug, and the major release 1.0.0 was published. I then updated the RustSec advisory to reflect that it was fixed. The following code contained the bug that caused undefined behavior: impl<T> BorshDeserialize for Vec<T> where T: BorshDeserialize, { #[inline] fn deserialize<R: Read>(reader: &mut R) -> Result<Self, Error> { let len = u32::deserialize(reader)?; if size_of::<T>() == 0 { let mut result = Vec::new(); result.push(T::deserialize(reader)?); let p = result.as_mut_ptr(); unsafe { forget(result); let len = len as usize; let result = Vec::from_raw_parts(p, len, len); Ok(result) } } else { // TODO(16): return capacity allocation when we can safely do that. let mut result = Vec::with_capacity(hint::cautious::<T>(len)); for _ in 0..len { result.push(T::deserialize(reader)?); } Ok(result) } } } Figure 1: Use of unsafe Rust (borsh-rs/borsh-rs/borsh/src/de/mod.rs#123–150) The code in figure 1 deserializes bytes to a vector of some generic data type T. If the type T is a zero-sized type, then unsafe Rust code is executed. The code first reads the requested length for the vector as u32. After that, the code allocates an empty Vec type. Then it pushes a single instance of T into it. Later, it temporarily leaks the memory of the just-allocated Vec by calling the forget function and reconstructs it by setting the length and capacity of Vec to the requested length. As a result, the unsafe Rust code assumes that T is copyable. The unsafe Rust code protects against a DoS attack where the deserialized in-memory representation is significantly larger than the serialized on-disk representation. The attack works by setting the vector length to a large number and using zero-sized types. An instance of this bug is described in our blog post Billion times emptiness. Case 2: DoS vector in Rust libraries for parsing the Ethereum ABI In July, I disclosed multiple DoS vulnerabilities in four Ethereum API–parsing libraries, which were difficult to report because I had to reach out to multiple parties. The bug affected four GitHub-hosted projects. Only the Python project eth_abi had GitHub private reporting enabled. For the other three projects (ethabi, alloy-rs, and ethereumjs-abi), I had to research who was maintaining them, which can be error-prone. For instance, I had to resort to the trick of getting email addresses from maintainers by appending the suffix .patch to GitHub commit URLs. The following link shows the non-work email address I used for committing: https://github.com/trailofbits/publications/commit/a2ab5a1cab59b52c4fa
71b40dae1f597bc063bdf.patch In summary, as the group of affected vendors grows, the burden on the reporter grows as well. Because you typically need to synchronize between vendors, the effort does not grow linearly but exponentially. Having more projects use the GitHub private reporting feature, a security policy with contact information, or simply an email in the README file would streamline communication and reduce effort. Read more about the technical details of this bug in the blog post Billion times emptiness. Case 3: Missing limit on authentication tag length in Expo In late 2022, Joop van de Pol, a security engineer at Trail of Bits, discovered a cryptographic vulnerability in expo-secure-store. In this case, the vendor, Expo, failed to follow up with us about whether they acknowledged or had fixed the bug, which left us in the dark. Even worse, trying to follow up with the vendor consumed a lot of time that could have been spent finding more bugs in open-source software. When we initially emailed Expo about the vulnerability through the email address listed on its GitHub, secure@expo.io, an Expo employee responded within one day and confirmed that they would forward the report to their technical team. However, after that response, we never heard back from Expo despite two gentle reminders over the course of a year. Unfortunately, Expo did not allow private reporting through GitHub, so the email was the only contact address we had. Now to the specifics of the bug: on Android above API level 23, SecureStore uses AES-GCM keys from the KeyStore to encrypt stored values. During encryption, the tag length and initialization vector (IV) are generated by the underlying Java crypto library as part of the Cipher class and are stored with the ciphertext: /* package */ JSONObject createEncryptedItem(Promise promise, String plaintextValue, Cipher cipher, GCMParameterSpec gcmSpec, PostEncryptionCallback postEncryptionCallback) throws GeneralSecurityException, JSONException { byte[] plaintextBytes = plaintextValue.getBytes(StandardCharsets.UTF_8); byte[] ciphertextBytes = cipher.doFinal(plaintextBytes); String ciphertext = Base64.encodeToString(ciphertextBytes, Base64.NO_WRAP); String ivString = Base64.encodeToString(gcmSpec.getIV(), Base64.NO_WRAP); int authenticationTagLength = gcmSpec.getTLen(); JSONObject result = new JSONObject() .put(CIPHERTEXT_PROPERTY, ciphertext) .put(IV_PROPERTY, ivString) .put(GCM_AUTHENTICATION_TAG_LENGTH_PROPERTY, authenticationTagLength); postEncryptionCallback.run(promise, result); return result; } Figure 2: Code for encrypting an item in the store, where the tag length is stored next to the cipher text (SecureStoreModule.java) For decryption, the ciphertext, tag length, and IV are read and then decrypted using the AES-GCM key from the KeyStore. An attacker with access to the storage can change an existing AES-GCM ciphertext to have a shorter authentication tag. Depending on the underlying Java cryptographic service provider implementation, the minimum tag length is 32 bits in the best case (this is the minimum allowed by the NIST specification), but it could be even lower (e.g., 8 bits or even 1 bit) in the worst case. So in the best case, the attacker has a small but non-negligible probability that the same tag will be accepted for a modified ciphertext, but in the worst case, this probability can be substantial. In either case, the success probability grows depending on the number of ciphertext blocks. Also, both repeated decryption failures and successes will eventually disclose the authentication key. For details on how this attack may be performed, see Authentication weaknesses in GCM from NIST. From a cryptographic point of view, this is an issue. However, due to the required storage access, it may be difficult to exploit this issue in practice. Based on our findings, we recommended fixing the tag length to 128 bits instead of writing it to storage and reading it from there. The story would have ended here since we didn’t receive any responses from Expo after the initial exchange. But in our second email reminder, we mentioned that we were going to publicly disclose this issue. One week later, the bug was silently fixed by limiting the minimum tag length to 96 bits. Practically, 96 bits offers sufficient security. However, there is also no reason not to go with the higher 128 bits. The fix was created exactly one week after our last reminder. We suspect that our previous email reminder led to the fix, but we don’t know for sure. Unfortunately, we were never credited appropriately. Case 4: DoS vector in the num-bigint Rust library In July 2023, Sam Moelius, a security engineer at Trail of Bits, encountered a DoS vector in the well-known num-bigint Rust library. Even though the disclosure through email worked very well, users were never informed about this bug through, for example, a GitHub advisory or CVE. The num-bigint project is hosted on GitHub, but GitHub private reporting is not set up, so there was no quick way for the library author or us to create an advisory. Sam reported this bug to the developer of num-bigint by sending an email. But finding the developer’s email is error-prone and takes time. Instead of sending the bug report directly, you must first confirm that you’ve reached the correct person via email and only then send out the bug details. With GitHub private reporting or a security policy in the repository, the channel to send vulnerabilities through would be clear. But now let’s discuss the vulnerability itself. The library implements very large integers that no longer fit into primitive data types like i128. On top of that, the library can also serialize and deserialize those data types. The vulnerability Sam discovered was hidden in that serialization feature. Specifically, the library can crash due to large memory consumption or if the requested memory allocation is too large and fails. The num-bigint types implement traits from Serde. This means that any type in the crate can be serialized and deserialized using an arbitrary file format like JSON or the binary format used by the bincode crate. The following example program shows how to use this deserialization feature: use num_bigint::BigUint; use std::io::Read; fn main() -> std::io::Result<()> { let mut buf = Vec::new(); let _ = std::io::stdin().read_to_end(&mut buf)?; let _: BigUint = bincode::deserialize(&buf).unwrap_or_default(); Ok(()) } Figure 3: Example deserialization format It turns out that certain inputs cause the above program to crash. This is because implementing the Visitor trait uses untrusted user input to allocate a specific vector capacity. The following figure shows the lines that can cause the program to crash with the message memory allocation of 2893606913523067072 bytes failed. impl<'de> Visitor<'de> for U32Visitor { type Value = BigUint; {...omitted for brevity...} #[cfg(not(u64_digit))] fn visit_seq<S>(self, mut seq: S) -> Result<Self::Value, S::Error> where S: SeqAccess<'de>, { let len = seq.size_hint().unwrap_or(0); let mut data = Vec::with_capacity(len); {...omitted for brevity...} } #[cfg(u64_digit)] fn visit_seq<S>(self, mut seq: S) -> Result<Self::Value, S::Error> where S: SeqAccess<'de>, { use crate::big_digit::BigDigit; use num_integer::Integer; let u32_len = seq.size_hint().unwrap_or(0); let len = Integer::div_ceil(&u32_len, &2); let mut data = Vec::with_capacity(len); {...omitted for brevity...} } } Figure 4: Code that allocates memory based on user input (num-bigint/src/biguint/serde.rs#61–108) We initially contacted the author on July 20, 2023, and the bug was fixed in commit 44c87c1 on August 22, 2023. The fixed version was released the next day as 0.4.4. Case 5: Insertion of MMKV database encryption key into Android system log with react-native-mmkv The last case concerns the disclosure of a plaintext encryption key in the react-native-mmkv library, which was fixed in September 2023. During a secure code review for a client, I discovered a commit that fixed an untracked vulnerability in a critical dependency. Because there was no security advisory or CVE ID, neither I nor the client were informed about the vulnerability. The lack of vulnerability management caused a situation where attackers knew about a vulnerability, but users were left in the dark. During the client engagement, I wanted to validate how the encryption key was used and handled. The commit fix: Don’t leak encryption key in logs in the react-native-mmkv library caught my attention. The following code shows the problematic log statement: MmkvHostObject::MmkvHostObject(const std::string& instanceId, std::string path, std::string cryptKey) { __android_log_print(ANDROID_LOG_INFO, "RNMMKV", "Creating MMKV instance \"%s\"... (Path: %s, Encryption-Key: %s)", instanceId.c_str(), path.c_str(), cryptKey.c_str()); std::string* pathPtr = path.size() > 0 ? &path : nullptr; {...omitted for brevity...} Figure 5: Code that initializes MMKV and also logs the encryption key Before that fix, the encryption key I was investigating was printed in plaintext to the Android system log. This breaks the threat model because this encryption key should not be extractable from the device, even with Android debugging features enabled. With the client’s agreement, I notified the author of react-native-mmkv, and the author and I concluded that the library users should be informed about the vulnerability. So the author enabled private reporting and together we published a GitHub advisory. The ID CVE-2024-21668 was assigned to the bug. The advisory now alerts developers if they use a vulnerable version of react-native-mmkv when running npm audit or npm install. This case highlights that there is basically no way around GitHub advisories when it comes to npm packages. The only way to feed the output of the npm audit command is to create a GitHub advisory. Using private reporting streamlines that process. Takeaways GitHub’s private reporting feature contributes to securing the software ecosystem. If used correctly, the feature saves time for vulnerability reporters and software maintainers. The biggest impact of private reporting is that it is linked to the GitHub advisory database—a link that is missing, for example, when using confidential issues in GitLab. With GitHub’s private reporting feature, there is now a process for security researchers to publish to that database (with the approval of the repository maintainers). The disclosure process also becomes clearer with a private report on GitHub. When using email, it is unclear whether you should encrypt the email and who you should send it to. If you’ve ever encrypted an email, you know that there are endless pitfalls. However, you may still want to send an email notification to developers or a security contact, as maintainers might miss GitHub notifications. A basic email with a link to the created advisory is usually enough to raise awareness. Step 1: Add a security policy Publishing a security policy is the first step towards owning a vulnerability reporting process. To avoid confusion, a good policy clearly defines what to do if you find a vulnerability. GitHub has two ways to publish a security policy. Either you can create a SECURITY.md file in the repository root, or you can create a user- or organization-wide policy by creating a .github repository and putting a SECURITY.md file in its root. We recommend starting with a policy generated using the Policymaker by disclose.io (see this example), but replace the Official Channels section with the following: We have multiple channels for receiving reports: * If you discover any security-related issues with a specific GitHub project, click the *Report a vulnerability* button on the *Security* tab in the relevant GitHub project: https://github.com/%5BYOUR_ORG%5D/%5BYOUR_PROJECT%5D.
* Send an email to security@example.com Always make sure to include at least two points of contact. If one fails, the reporter still has another option before falling back to messaging developers directly. Step 2: Enable private reporting Now that the security policy is set up, check out the referenced GitHub private reporting feature, a tool that allows discreet communication of vulnerabilities to maintainers so they can fix the issue before it’s publicly disclosed. It also notifies the broader community, such as npm, Crates.io, or Go users, about potential security issues in their dependencies. Enabling and using the feature is easy and requires almost no maintenance. The only key is to make sure that you set up GitHub notifications correctly. Reports get sent via email only if you configure email notifications. The reason it’s not enabled by default is that this feature requires active monitoring of your GitHub notifications, or else reports may not get the attention they require. After configuring the notifications, go to the “Security” tab of your repository and click “Enable vulnerability reporting”: Emails about reported vulnerabilities have the subject line “(org/repo) Summary (GHSA-0000-0000-0000).” If you use the website notifications, you will get one like this: If you want to enable private reporting for your whole organization, then check out this documentation. A benefit of using private reporting is that vulnerabilities are published in the GitHub advisory database (see the GitHub documentation for more information). If dependent repositories have Dependabot enabled, then dependencies to your project are updated automatically. On top of that, GitHub can also automatically issue a CVE ID that can be used to reference the bug outside of GitHub. This private reporting feature is still officially in beta on GitHub. We encountered minor issues like the lack of message templates and the inability of reporters to add collaborators. We reported the latter as a bug to GitHub, but they claimed that this was by design. Step 3: Get notifications via webhooks If you want notifications in a messaging platform of your choice, such as Slack, you can create a repository- or organization-wide webhook on GitHub. Just enable the following event type: After creating the webhook, repository_advisory events will be sent to the set webhook URL. The event includes the summary and description of the reported vulnerability. How to make security researchers happy If you want to increase your chances of getting high-quality vulnerability reports from security researchers and are already using GitHub, then set up a security policy and enable private reporting. Simplifying the process of reporting security bugs is important for the security of your software. It also helps avoid researchers becoming annoyed and deciding not to report a bug or, even worse, deciding to turn the vulnerability into an exploit or release it as a 0-day. If you use GitHub, this is your call to action to prioritize security, protect the public software ecosystem’s security, and foster a safer development environment for everyone by setting up a basic security policy and enabling private reporting. If you’re not a GitHub user, similar features also exist on other issue-tracking systems, such as confidential issues in GitLab. However, not all systems have this option; for instance, Gitea is missing such a feature. The reason we focused on GitHub in this post is because the platform is in a unique position due to its advisory database, which feeds into, for example, the npm package repository. But regardless of which platform you use, make sure that you have a visible security policy and reliable channels set up.

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.

Ransomware attacks are targeting healthcare organizations more frequently. The number of costly cyberattacks on US hospitals has doubled. So how do you prevent these attacks? Keep reading to learn five ways you can strengthen security at your organization. But first, let’s find out what’s at stake. Why healthcare needs better cybersecurity Healthcare organizations are especially vulnerable to data breaches because of how much data they hold. And when a breach happens, it creates financial burdens and affects regulatory compliance. On average, the cost of a healthcare data breach globally is $10.93 million. Noncompliance not only incurs more costs but also hurts patient trust. Once that trust is lost, it’s difficult to regain it, which can impact your business and standing within the industry. Adopting a layered security approach will help your organization prevent these attacks. Here are five ways to strengthen your cybersecurity: 1. Use preventive security technology Prevention, as the saying goes, prevention is better than the cure. With the right systems and the right methodology, it’s possible to detect and intercept most cyberthreats before they lead to a data breach, a loss of service, or a deterioration in patient care.
Examples of prevention-layer technologies include:

• Endpoint protection keeps out malicious files, scripts, URLs, and exploits via a cloud-based architecture.
• Email encryption makes it hard for attackers to intercept sensitive medical data—just make sure the encryption tool is easy to manage and use.
• Email threat protection and continuity safeguards electronic medical records by monitoring emerging threats.

2. Provide cybersecurity training According to Verizon, 82 percent of all breaches involve a human element. Sometimes malicious insiders create security vulnerabilities. Other times, well-intentioned employees fall victim to attacks like phishing, legitimate-looking emails that trick employees into giving attackers their credentials or other sensitive information—like patient data. In fact, 16 percent of breaches start with phishing. When your employees receive basic cybersecurity training, they are more likely to recognize bad actors, report suspicious activity, and avoid risky behavior. You can outsource cybersecurity training or find an automated security training solution that you manage. 3. Ensure regulatory compliance Healthcare providers are subject to strict data privacy regulations like HIPPA and GDPR. If an avoidable data breach occurs, organizations face hefty fines from state and federal authorities. The email and endpoint protection tools described above help you stay compliant with these regulations. But sometimes a breach is out of your control. So regulators have provided guidelines for how to respond, including investigation, notification, and recovery. 4. Build business recovery plans Adding a recovery plan to your multilayered security approach is crucial to achieving and maintaining cyber resilient healthcare. Ideally, you’ll catch most incoming threats before they become an issue. However, the recovery layer is critical when threats do get through or disasters occur. You might think that your cloud-based applications back up and secure your data. But SaaS vendors explicitly state that data protection and backup is the customer’s responsibility of the customer. Some SaaS applications have recovery options, but they’re limited and ineffective. A separate backup system is necessary to ensure business continuity. Reasons for implementing a solid recovery strategy include:

• Re-establishing patient trust.
• Avoiding disruptions to patient care.
• Remaining compliant with HIPPA and GDPR requirements.

Remember, lives depend on getting your systems back up quickly. That’s why your healthcare organization needs a secure, continuously updated backup and recovery solution for local and cloud servers. 5. Monitor and improve continuously Once you have your multilayered security approach in place, you’ll need a centralized management console to help you monitor and control all your security services. This single-pane-of-glass gives you real-time cyber intelligence and all the tools you need to protect your healthcare organization, your reputation, and your investment in digital transformation. You can also spot gaps in your approach and find ways to improve. Conclusion Cybersecurity can seem daunting at times. Just remember that every step you take toward cyber resilience helps you protect patient privacy and maintain your credibility within the healthcare industry.
So when you’re feeling overwhelmed or stuck, remember the five ways you can strengthen your layered cybersecurity approach:

1. Use preventive technology like endpoint protection and email encryption.
2. Train your employees to recognize malicious activities like phishing.
3. Ensure that you’re compliant with HIPPA, GDPR, and any other regulation standards.
4. Retrieve your data from breaches with backup and recovery tools.
5. Monitor your data and improve your approach when necessary.

The post 5 ways to strengthen healthcare cybersecurity appeared first on Webroot Blog.

Additive manufacturing (AM) engineers have been incredibly creative in developing ancillary systems that modify a printed parts mechanical properties.  These systems mostly focus on the issue of anisotropic properties of additively built components.  This blog post is a good reference if you are unfamiliar with isotropic vs anisotropic properties and how they impact 3d printing.  […] The post Cybersecurity Concerns for Ancillary Strength Control Subsystems appeared first on BreakPoint Labs - Blog.

To consolidate all of our security intelligence and news in one location, we have migrated Naked Security to the Sophos News platform.