A cyberattack on the Zug-based procurement service provider Chain IQ apparently has far-reaching consequences for UBS: data from 130,000 employees, including the direct number of CEO Sergio Ermotti, is said to have ended up on the darknet.
US-designated terrorist organization ELN oversees a vast digital operation that promotes pro-Kremlin and anti-US content.
The National Liberation Army (ELN), a Colombian armed group that also holds influence in Venezuela, has built a digital strategy that involves branding themselves as media outlets to build credibility, overseeing a diffuse cross-platform operation, and using these wide-ranging digital assets to amplify Russian, Iranian, Venezuelan, and Cuban narratives that attack the interests of the United States, the European Union (EU), and their allies.
In the 1960s, the ELN emerged as a Colombian nationalist armed movement ideologically rooted in Marxism-Leninism, liberation theology, and the Cuban revolution. With an army estimated to have 2,500 to 6,000 members, the ELN is Colombia’s oldest and largest active guerrilla group, with its operation extending into Venezuela. The ELN has maintained a strategic online presence for over a decade to advance its propaganda and maintain operational legitimacy.
The organization, which has previously engaged in peace talks with the Colombian state, has carried out criminal activities in Colombia and Venezuela, such as killings, kidnappings, extortions, and the recruitment of minors. After successive military and financial crises in the 1990s, the armed group abandoned its historical reluctance to participate in drug trafficking. The diversification into illegal funding has meant that their armed clashes target criminal groups, in addition to their primary ideological enemy, the state forces.
In the north-eastern Catatumbo area, considered one of the enclaves of international cocaine trafficking, the group has been involved in one of the bloodiest confrontations seen in Colombia in 2025. Since January 15, the violence has left 126 people dead, at least 66,000 displaced, and has further strained the group’s engagement with the latest round of peace talks initiated by the current Colombian government. In that region, the ELN has battled with the state and other criminal groups, such as paramilitaries and other guerrilla groups, for extended control of the area bordering Venezuela, an effort to connect the ELN’s other territories of influence to Colombia, such as the north and, at the other extreme, the western regions of Choco and Antioquia.
The US Department of State reaffirmed the ELN’s designation as a terrorist organization in its March 5, 2025, update of the Foreign Terrorist Organizations (FTOs) list. This classification theoretically prevents the group from operating on major social media platforms, as US social media platforms, such as Meta, YouTube, and X, maintain policies prohibiting terrorist organizations from using their services. However, the DFRLab found that the group’s substantial digital footprint spans over one hundred entities across websites, social media, closed messaging apps, and podcast services.
On June 16, GreyNoise observed exploit attempts targeting CVE-2023-28771 — a remote code execution vulnerability affecting Zyxel Internet Key Exchange (IKE) packet decoders over UDP port 500.
CVE: CVE-2023-28771
Exploit method: UDP port 500 (IKE packet decoder)
Date observed: June 16, 2025
Duration of activity: One day (June 16, 2025)
Unique IPs: 244
Top destination countries: U.S., U.K., Spain, Germany, India.
IP classification: All malicious per GreyNoise
Infrastructure: Verizon Business (all IPs geolocated to U.S.)
Spoofable traffic: Yes (UDP-based)
Observed Activity
Exploitation attempts against CVE-2023-28771 were minimal throughout recent weeks. On June 16, GreyNoise observed a concentrated burst of exploit attempts within a short time window, with 244 unique IPs observed attempting exploitation.
The top destination countries were the U.S., U.K., Spain, Germany, and India.
Historical analysis indicates that in the two weeks preceding June 16, these IPs were not observed engaging in any other scanning or exploit behavior — only targeting CVE-2023-28771.
SafetyDetectives’ Cybersecurity Team stumbled upon a clear web forum post where a threat actor publicized a database that allegedly belongs to VirtualMacOSX.com. The data purportedly belongs to 10,000 of its customers.
In a recent discovery, SafetyDetectives’ Cybersecurity Team stumbled upon a clear web forum post where a threat actor publicized a database that allegedly belongs to VirtualMacOSX.com. The data purportedly belongs to 10,000 of its customers.
What Is VirtualMacOSX.com?
According to its website, VirtualMacOSX serves 102 countries and has offered “Apple Macintosh cloud based computing since 2012. With the greatest range of cloud based Apple products and services available anywhere on the Web.”
Where Was The Data Found?
The data was found in a forum post available on the clear surface web. This well-known forum operates message boards dedicated to database downloads, leaks, cracks, and more.
What Was Leaked?
The author of the post included a 34-line sample of the database, the full database was set to be freely accessible to anyone with an account on the forum willing to either reply or like the post.
Our Cybersecurity Team analyzed a segment of the dataset to validate its authenticity. Although the data appeared genuine and we saw indicatives in invoices sent to VirtualMacOSX, we could not definitively confirm that the data belonged to VirtualMacOSX’s customers as, due to ethical considerations, we refrained from testing the exposed credentials.
The entire dataset consisted of 176,000 lines split across three separate .txt files named ‘tblcontacts,’ ‘tbltickets,’ and ‘tblclients.’
The sensitive information allegedly belonging to VirtualMacOSX’s customers included:
User ID
Full name
Company name
Email
Full physical address
Phone number
Password
Password reset key
We also saw customers’ financial data such as:
Bank name
Bank type
Bank code
Bank account
And User’s Support tickets containing:
User ID
IP Address
Full name
Email
Full Message
This type of data is critical as it might be employed by potential wrongdoers to plan and perform various types of attacks on the impacted clients.
The pro-Israeli hacktivist group Predatory Sparrow claimed on Tuesday to have hacked and taken down Iran’s Bank Sepah.
The group, which is also known by its Persian name Gonjeshke Darande, claimed responsibility for the hack on X.
“We, ‘Gonjeshke Darande,’ conducted cyberattacks which destroyed the data of the Islamic Revolutionary Guard Corps’ ‘Bank Sepah,’” the group wrote.
The group claimed Bank Sepah is an institution that “circumvented international sanctions and used the people of Iran’s money to finance the regime’s terrorist proxies, its ballistic missile program and its military nuclear program.”
According to the independent news site Iran International, there are reports of “widespread banking disruptions” across the country. Iran International said several Bank Sepah branches were closed on Tuesday, and customers told the publication that they were unable to access their accounts.
Ariel Oseran, a correspondent for i24NEWS, posted pictures of ATMs in Iran displaying an error message.
TechCrunch could not independently verify the group’s alleged cyberattack. We reached out to two Bank Sepah Iranian email addresses, but the messages returned an error. Bank Sepah’s affiliates in the U.K. and Italy did not immediately respond to requests for comment.
Predatory Sparrow did not respond to a request for comment sent to their X account, and via Telegram.
The alleged cyberattack on Bank Sepah comes as Israel and Iran are bombing each other’s countries, a conflict that started after Israel began targeting nuclear energy facilities, military bases, and senior Iranian military officials on Friday.
It’s unclear who is behind Predatory Sparrow. The group clearly fashions itself as a pro-Israel or at least anti-Iran hacktivist group and has targeted companies and organizations in Iran for years. Cybersecurity researchers believe the group has had success in the past and made credible claims.
Learn about the new permission prompt for sites that connect to local networks.
Published: June 9, 2025
Chrome is adding a new permission prompt for sites that make connections to a user's local network as part of the draft Local Network Access specification. The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user's local network.
To understand how this change impacts the web ecosystem, the Chrome team is looking for feedback from developers who build web applications that rely on making connections to a user's local network or to software running locally on the user's machine. From Chrome 138, you can opt-in to these new restrictions by going to chrome://flags/#local-network-access-check and setting the flag to "Enabled (Blocking)".
Note: Chrome previously experimented with restricting access to local network devices with Private Network Access, which required CORS preflights where the target device opted in to being connected to, instead of gating all local network accesses behind a permission prompt. Local Network Access replaces that effort, after PNA was put on hold. Thank you to everyone who helped test PNA and provide feedback to us—it has been incredibly valuable and helped guide us to our new Local Network Access permission approach.
What is Local Network Access?
Local Network Access restricts the ability of websites to send requests to servers on a user's local network (including servers running locally on the user's machine), requiring the user grant the site permission before such requests can be made. The ability to request this permission is restricted to secure contexts.
A prompt with the text 'Look for and connect to any device on your local network.'
Example of Chrome's Local Network Access permission prompt.
Many other platforms, such as Android, iOS, and MacOS have a local network access permission. For example, you may have granted this permission to access the local network to the Google Home app when setting up new Google TV and Chromecast devices.
What kinds of requests are affected?
For the first milestone of Local Network Access, we consider a "local network request" to be any request from the public network to a local network or loopback destination.
A local network is any destination that resolves to the private address space defined in Section 3 of RFC1918 in IPv4 (e.g., 192.168.0.0/16), an IPv4-mapped IPv6 address where the mapped IPv4 address is itself private, or an IPv6 address outside the ::1/128, 2000::/3, and ff00::/8 subnets.
Loopback is any destination that resolves to the "loopback" space (127.0.0.0/8) defined in section 3.2.1.3 of RFC1122 of IPv4, the "link-local" space (169.254.0.0/16) defined in RFC3927 of IPv4, the "Unique Local Address" prefix (fcc00::/7) defined in Section 3 of RFC4193 of IPv6, or the "link-local" prefix (fe80::/10) defined in section 2.5.6 of RFC4291 of IPv6.
A public network is any other destination.
Note: In the future, we plan to extend these protections to cover all cross-origins requests going to destinations on the local network. This would include requests from a local server (for example, https://router.local) to other servers on the local network, or from a local server to localhost.
Because the local network access permission is restricted to secure contexts, and it can be difficult to migrate local network devices to HTTPS, the permission-gated local network requests will now be exempted from mixed content checks if Chrome knows that the requests will be going to the local network before resolving the destination. Chrome knows a request is going to the local network if:
The request hostname is a private IP literal (e.g., 192.168.0.1).
The request hostname is a .local domain.
The fetch() call is annotated with the option targetAddressSpace: "local".
// Example 1: Private IP literal is exempt from mixed content.
fetch("http://192.168.0.1/ping");
// Example 2: .local domain is exempt from mixed content.
fetch("http://router.local/ping");
// Example 3: Public domain is not exempt from mixed content,
// even if it resolves to a local network address.
fetch("http://example.com/ping");
// Example 4: Adding the targetAddressSpace option flags that
// the request will go to the local network, and is thus exempt
// from mixed content.
fetch("http://example.com/ping", {
targetAddressSpace: "local",
});
What's changing in Chrome
Chrome 138
Our initial version of Local Network Access is ready for opt-in testing in Chrome 138. Users can enable the new permission prompt by setting chrome://flags#local-network-access-check to "Enabled (Blocking)". This supports triggering the Local Network Access permission prompt for requests initiated using the JavaScript fetch() API, subresource loading, and subframe navigation.
A demo site is available at https://local-network-access-testing.glitch.me/ for triggering different forms of local network requests.
Known issues and limitations
The new permission prompt is currently only implemented on Desktop Chrome. We are actively working on porting it to Android Chrome. (Tracked in crbug.com/400455013.)
WebSockets (crbug.com/421156866), WebTransport (crbug.com/421216834), and WebRTC (crbug.com/421223919) connections to the local network are not yet gated on the LNA permission.
Local network requests from Service Workers currently require that the service worker's origin has previously been granted the Local Network Access permission.
If your application makes local network requests from a service worker, you will currently need to separately trigger a local network request from your application in order to trigger the permission prompt. (We are working on a way for workers to trigger the permission prompt if there is an active document available—see crbug.com/404887282.)
Chrome 139 and beyond
Our intent is to ship Local Network Access as soon as possible. Recognizing that some sites may need additional time to be updated with Local Network Access annotations, we will add an Origin Trial to let sites temporarily opt-out of the secure contexts requirement before we ship Local Network Access by default. This should provide a clearer migration path for developers, especially if you rely on accessing local network resources over HTTP (as these requests would be blocked as mixed content if requested from an HTTPS page in browsers that don't yet support the Local Network Access mixed content exemption).
We will also be adding a Chrome enterprise policy for controlling which sites can and cannot make local network requests (pre-granting or pre-denying the permission to those sites). This will allow managed Chrome installations, such as those in corporate settings, to avoid showing the warning for known intended use cases, or to further lock down and prevent sites from being able to request the permission at all.
We plan to continue integrating the Local Network Access permission with different features that can send requests to the local network. For example, we plan to ship Local Network Access for WebSockets, WebTransport, and WebRTC connections soon.
We will share more information as we get closer to being able to fully launch Local Network Access in Chrome.
Issue Details
CVE-2025-23121
A vulnerability allowing remote code execution (RCE) on the Backup Server by an authenticated domain user.
Severity: Critical
CVSS v3.0 Score: 9.9
Source: Reported by watchTowr and CodeWhite.
Note: This vulnerability only impacts domain-joined backup servers.
Veeam Backup & Replication Security Best Practice Guide > Workgroup or Domain?
Affected Product
Veeam Backup & Replication 12.3.1.1139 and all earlier version 12 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Backup & Replication 12.3.2 (build 12.3.2.3617)CVE-2025-24286
A vulnerability allowing an authenticated user with the Backup Operator role to modify backup jobs, which could execute arbitrary code.
Severity: High
CVSS v3.1 Score: 7.2
Source: Reported by Nikolai Skliarenko with Trend Micro.
Affected Product
Veeam Backup & Replication 12.3.1.1139 and all earlier version 12 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Backup & Replication 12.3.2 (build 12.3.2.3617)CVE-2025-24287
A vulnerability allowing local system users to modify directory contents, allowing for arbitrary code execution on the local system with elevated permissions.
Severity: Medium
CVSS v3.1 Score: 6.1
Source: Reported by CrisprXiang working with Trend Micro Zero Day Initiative.
Affected Product
Veeam Agent for Microsoft Windows 6.3.1.1074 and all earlier version 6 builds.
Note: Unsupported product versions are not tested, but are likely affected and should be considered vulnerable.
Solution
This vulnerability was fixed starting in the following build:
Veeam Agent for Microsoft Windows 6.3.2 (build 6.3.2.1205)
Veeam Agent for Microsoft Windows is included with Veeam Backup & Replication and available as a standalone application.Severity - Critical
Description of Problem
A vulnerability has been discovered in NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway). Refer below for further details.
Affected Versions
The following supported versions of NetScaler ADC and NetScaler Gateway are affected by the vulnerabilities:
NetScaler ADC and NetScaler Gateway 14.1 BEFORE 14.1-43.56
NetScaler ADC and NetScaler Gateway 13.1 BEFORE 13.1-58.32
NetScaler ADC 13.1-FIPS and NDcPP BEFORE 13.1-37.235-FIPS and NDcPP
NetScaler ADC 12.1-FIPS BEFORE 12.1-55.328-FIPSDetails
NetScaler ADC and NetScaler Gateway contain the vulnerabilities mentioned below:
CVE ID Description Pre-conditions CWE CVSSv4
CVE-2025-5349 Improper access control on the NetScaler Management Interface Access to NSIP, Cluster Management IP or local GSLB Site IP CWE-284: Improper Access Control
CVSS v4.0 Base Score: 8.7
(CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
CVE-2025-5777 Insufficient input validation leading to memory overread NetScaler must be configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) OR AAA virtual server CWE-125: Out-of-bounds Read
CVSS v4.0 Base Score: 9.3
(CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L)
Elastic Security Labs has observed the ClickFix technique gaining popularity for multi-stage campaigns that deliver various malware through social engineering tactics.
Our threat intelligence indicates a substantial surge in activity leveraging ClickFix (technique first observed) as a primary initial access vector. This social engineering technique tricks users into copying and pasting malicious PowerShell that results in malware execution. Our telemetry has tracked its use since last year, including instances leading to the deployment of new versions of the GHOSTPULSE loader. This led to campaigns targeting a broad audience using malware and infostealers, such as LUMMA and ARECHCLIENT2, a family first observed in 2019 but now experiencing a significant surge in popularity.
This post examines a recent ClickFix campaign, providing an in-depth analysis of its components, the techniques employed, and the malware it ultimately delivers.
Key takeaways
Today was an eventful day thanks to many interesting blog posts, e.g. from my friends at watchTowr. So I thought, why not publish a small quick-and-dirty blog post myself about a story from last week? This blog post may not be of the usual quality, but it was a good time to write it.