Today’s topic is the NIS 2 Directive, which aims to improve the cyber-resilience of critical infrastructure and essential and important entities. NIS 2 looks set to do for information security in the EU what GDPR did for user data privacy.

It won’t be long now before the new directive will be transposed into national law, so if your organization is not yet ready, now’s the time to take steps.

What is NIS 2?

The revised Network and Information Security Directive (NIS 2) is the EU-wide legislation on cybersecurity. NIS 2 updates and complements the original NIS Directive, adopted in 2016, and creates a legal framework to enhance the overall level of cybersecurity across the EU.

The updated NIS 2 Directive focuses on three main areas:

Expanding the scope of application: the seven sectors covered by the original NIS Directive are supplemented by a number of new ones
New mechanisms for incident reporting and information sharing: NIS 2 mandates the timely reporting of significant incidents
Tighter enforcement of compliance: the updated NIS 2 introduces specific sanctions for non-compliance, including fines of up to 2% of global annual turnover

What organizations does NIS 2 apply to?

As mentioned above, the revised directive significantly broadens the scope of application compared to the original 2016 version. In addition, NIS 2 introduces a classification that divides the covered sectors into two categories:

Sectors of high criticality (Annex I):

Energy (electricity, district heating & cooling, gas, hydrogen, oil)
Transport (air, rail, water, road)
Banking
Financial market infrastructure
Health
Drinking water
Waste water
Digital infrastructure
ICT-service management (MSP, MSSP)
Public administration entities
Space

Other critical sectors (Annex II):

Postal and courier services
Waste management
Manufacture, production, and distribution of chemicals
Production, processing, and distribution of food
Manufacturing (medical devices, computer, electronic, or optical products, electrical equipment, machinery, motor vehicles, other transport equipment)
Digital providers
Research

Besides classifying sectors, NIS 2 introduces an additional classification of specific entities. It too consists of two categories:

Essential (Article 3.1):

Large entities (annual revenue of over €50 million) in sectors of high criticality
Certification authorities, top-level domain registrars, and DNS providers, regardless of size of the business
Telecom providers, from medium-sized upwards (revenue over €10 million)
Public administration institutions
Any entity belonging to a highly critical or other critical sector that’s defined by an EU Member State as essential
Entities defined as critical under Directive (EU) 2022/2557

Important (Article 3.2):

Medium-sized entities (annual revenue of €10-50 million) in highly critical sectors
Medium and large entities in other critical sectors
Any entity that’s defined by an EU Member State as important

The category an entity belongs to has significant practical implications. The activities of entities classified as essential will be subject to much stricter and proactive oversight, including random raids, special security checks, and requests for proof of compliance. For non-compliance with NIS 2, essential entities may face a fine of up to €10 million or 2% of global annual turnover.

Entities classified as important can breathe a bit more easily — they’re subject to less stringent controls. For important entities, the penalties are slightly more modest: up to €7 million or 1.4% of global annual turnover.

NIS 2 timeline

Note that, unlike GDPR, NIS 2 is a directive, — not a regulation of the European Union. This means that EU Member States are legally required to amend their national legislation within the designated time frame. In the case of NIS 2, the deadline is set for October 17, 2024.

In addition, EU Member States will have to draw up lists of essential and important entities subject to NIS 2 by April 17, 2025.

It will be useful to revisit the timeline of the main stages of NIS 2:

July 6, 2016: adoption of Directive (EU) 2016/1148, the original NIS
May 9, 2018: deadline for EU Member States to transpose the NIS Directive into their national legislation
July 7, 2020: start of European Commission (EC) consultations on the revision of NIS
December 16, 2020: publication of the proposal for NIS2 by the EC
May 13, 2022: European Parliament vote on adoption of the NIS 2 Directive
November 10, 2022: approval of the NIS 2 Directive by the Council of the EU
December 14, 2022: publication of the NIS 2 Directive in the Official Journal of the EU under the title Directive (EU) 2022/2555
January 16, 2023: entry into force of the NIS 2 Directive
October 17, 2024: deadline for EU Member States to transpose the NIS 2 Directive into their national legislation
April 17, 2025: deadline for EU Member States to draw up lists of essential and important These lists must be updated regularly thereafter — at least every two years
October 17, 2027: review of the NIS 2 Directive

How to prepare for NIS 2 implementation?

Assess whether, and to what extent, the requirements of NIS 2 apply to your organization
Investigate how the NIS Directive was transposed into the national legislation in your EU Member State
Follow the recommendations of national cybersecurity authorities
Assess and develop technical, operational, and organizational measures for managing network and information systems; security risks

More information about the updated EU Network and Information Security Directive, and how organizations can prepare for its entry into force, is available on our dedicated NIS 2 site.

Kaspersky official blog – ​Read More

Every time someone with a smartphone with GPS enabled passes by near your Wi-Fi access point, the approximate geographic coordinates of your router are uploaded to the databases of Apple, Google and other tech giants. This is an integral part of the Wi-Fi Positioning System (WPS). For your router to end up in this database, you don’t even need to have a smartphone yourself — it’s enough for a neighbor or passer-by to have one.

WPS is what enables you to see your location almost immediately when you open a map app. Relying on “pure” GPS data from satellites would take a few minutes. Your smartphone checks which Wi-Fi access points are nearby, sends the list to Google or Apple, and receives either its calculated coordinates (from Google) or a list of router coordinates (from Apple) to calculate its own position.

Even devices without GPS, such as laptops, can also use this type of geolocation. As discovered by researchers at MIT, Apple places minimal restrictions on requests for access point coordinates, making it possible to create your own worldwide router map and use it to find interesting phenomena and patterns, or even track individuals.

What are the risks inherent in router surveillance?

While the approximate physical location of a router might not seem like particularly confidential data, especially for those living in your area, there are several cases when it’s best to keep this information hidden. Here are a just a few examples:

When using satellite internet terminals, such as Starlink. These provide internet access via Wi-Fi, and tracking the terminal equals tracking the user’s location. This is particularly sensitive when terminals are used in military conflict or emergency zones.
When using mobile hotspots for business and travel. If you find it convenient to share internet from a mobile router to your laptop and other devices, your pocket hotspot likely accompanies you on business trips. This creates opportunities to monitor your travel schedule, frequency and directions. The same applies to hotspots installed in RVs and yachts.
When people have moved. Often, a router moves with its owner, revealing their new address to anyone who’s previously connected to their Wi-Fi — even just once before. While this is usually harmless, it can be problematic for those relocating to escape harassment, domestic violence or other serious issues.

The limitations of WPS tracking

These are all valid concerns, but there’s good news: WPS tracking is less accurate and slower than other surveillance methods.

First of all, for a router to be added to the WPS database, it must be consistently detected in the same area over some time. MIT researchers found that a new router took between two and seven days to appear in the WPS database. If you go somewhere with a mobile router for a short period, this movement is unlikely to be recorded in the database.

Secondly, a router must be scanned by several smartphones with activated geolocation services to be included in the WPS database. Therefore, a router installed in an isolated or unpopulated area may never appear on the map.

Thirdly, the identification and further tracking of routers relies on a BSSID — an identifier broadcast by the access point. Wi-Fi standards allow for BSSID randomization, and if this feature is enabled, the identifier automatically changes at certain time intervals. This doesn’t interfere with the normal operation of devices connected to the access point, but it does make it more difficult to re-identify the router. Just like the private MAC address setting in Android, iOS and Windows reduces the risk of tracking client devices, BSSID randomization makes it much more difficult to track access points.

How to protect your router from WPS tracking

Both Apple and Google have a little-known tool that allows you to exclude an access point from WPS databases. To do this, add the suffix _nomap to the end of the access point name. For example, the access point MyHomeWifi should be renamed MyHomeWifi_nomap.

For home and office routers, an additional security measure is to rent a device from the provider rather than buying your own. Then, whenever you move, you can simply return it and rent a new router at the new location.

A more technologically advanced solution, though more complicated to implement, would be to use a router that supports BSSID randomization — such as those from Supernetworks with open-source firmware. The popular alternative firmware for routers, DD-WRT, also allows for BSSID randomization if supported by the hardware.

For those using a smartphone as an access point, we recommend reviewing the device settings. On Apple devices, enabling BSSID randomization for your hotspot is not very straightforward — there’s no such switch directly in the Personal Hotspot settings. However, if the Private Wi-Fi Address feature is enabled for at least some Wi-Fi networks (Settings → Wi-Fi → tap the name of the connected Wi-Fi network → enable Private Wi-Fi Address), then your hotspot will start randomizing the BSSID of the access point. This feature can also occasionally be found on Android smartphones, although the activation process varies by manufacturer.

According to Starlink, their terminals have also gradually been receiving a software update since early 2023 that automatically activates BSSID randomization.

Kaspersky official blog – ​Read More

A security researcher known as mr.d0x has published a post detailing a new technique that can be used for phishing and potentially other malicious activities. The technique exploits so-called progressive web apps (PWAs). In this post, we discuss what these applications are, why they can be dangerous, how attackers can use them for their own purposes, and how to [placeholder Kaspersky Premium]protect yourself[/placeholder] against this threat.

What are progressive web apps?

PWAs are applications developed using web technologies. Essentially, they’re websites that look and function just like native applications installed on your operating system.

The general idea is similar to applications built on the Electron framework, with one key difference. Electron apps are like a “sandwich” of a website (the filling) and a browser (the bread) dedicated to running that site; that is, each Electron application has a built-in browser. In contrast, PWAs utilize the engine of the browser already installed on the user’s system to display the same website – like a sandwich without the bread.

All modern browsers support PWAs, with Google Chrome and Chromium-based browsers (including the Microsoft Edge browser that comes with Windows) offering the most comprehensive implementation.

Installing a PWA (if the respective website supports it) is very simple. Just click an inconspicuous button in the browser’s address bar and confirm the installation. Here’s how it’s done, using the Google Drive PWA as an example:

After that, the PWA appears on your system almost instantly, looking just like a real application — with an icon, its own window, and all the other attributes of a fully-fledged program. It’s not easy to tell from the PWA window that it’s actually a browser displaying a website.

PWA-based phishing

One crucial difference between a PWA and the same website opened in a browser is evident in the screenshot above: the PWA window lacks an address bar. This very feature forms the foundation of the phishing method discussed in this post.

With no address bar in the window, attackers can simply draw their own — displaying an URL that serves their phishing goals. For example, this one:

Attackers can further enhance the deception by giving the PWA a familiar icon.

The only remaining hurdle is convincing the victim to install the PWA. However, this can be easily achieved with persuasive language and cleverly designed interface elements.

It’s important to note that during the PWA installation dialog, the displayed app name can be anything the attacker desires. The true origin is only revealed by the website address in the second line, which is less noticeable:

The process of stealing a password using a PWA generally unfolds as follows:

The victim opens a malicious website.
The website convinces the victim to install the PWA.
Installation occurs almost instantly, and the PWA window opens.
A phishing page with a fake address bar displaying a legitimate-looking URL opens in the PWA window.
The victim enters their login credentials into the form — handing them directly to the attackers.

Of course, convincing the victim to install a native application is just as straightforward, but there are a couple of nuances. PWAs install significantly faster and require much less user interaction compared to traditional app installations.

Additionally, developing PWAs is simpler, as they’re essentially phishing websites with minor enhancements. These factors make malicious PWAs a powerful tool for cybercriminals.

How to protect yourself from PWA phishing

Incidentally, the same mr.d0x previously gained recognition for devising the browser-in-the-browser phishing technique, which we wrote about a couple of years ago. Since then there have been several reported instances of attackers employing this technique not only for stealing account passwords but also for spreading ransomware.

Given this precedent, it’s highly probable that cybercriminals will adopt malicious PWAs and devise novel ways to exploit this technique beyond phishing.

What can you do to protect against this threat?

Exercise caution when encountering PWAs, and refrain from installing them from suspicious websites.
Periodically review the list of PWAs installed on your system. For instance, in Google Chrome, type chrome://apps into the address bar to view and manage installed PWAs.

Use a reliable security solution with protection against phishing and fraudulent sites, which will promptly warn you of potential dangers.

Kaspersky official blog – ​Read More

Organizations are adopting biometric authentication to optimize access control and to add a primary or auxiliary authentication factor for accessing corporate information systems. Biometrics are perfect for the job: such data can’t be forgotten like a password, or lost like a keypass, and is very hard to forge. Security no longer has to deal with lost or forgotten cards, and the IT security team doesn’t need to come up with OTP systems. However, there are a number of “buts” to consider when evaluating such implementations:

Risks associated with storing and processing biometric information (regulated by law in many countries);
Practical difficulties related to false positives and negatives (strongly dependent on the type of biometrics and means of verification);
Risks of authentication bypass;
Risks of cyberattacks through vulnerabilities in the biometric terminal.

The first two points are usually covered by security personnel, but the rest are often underestimated. Yet, as our in-depth study of popular ZKTeco biometric terminals shows, by no means are they far-fetched. These terminals were found to harbor 24 vulnerabilities that allow threat actors to effortlessly bypass authentication, hijack the device, read or modify the list of users, download their photos and other data, and exploit access to the device to develop an attack on the corporate network. Here’s how attackers can use these vulnerabilities.

QR code instead of a face

The biometric terminal model studied by our experts can store a database of users locally and authenticate them in one of several ways: password, QR code, face photo biometrics, or electronic pass. As it turned out, simply scanning a QR code containing the trivial SQL injection is enough to validate authentication on the device and open the doors. And if too much data is embedded in the QR code, the terminal reboots. To carry out these attacks, an attacker only needs to approach the device with a phone or even a paper card.

Insecure network access

The terminal can be managed either locally or over the network using SSH or a proprietary network protocol using the TCP port 4370. The protocol requires authentication, but the procedure’s implementation contains serious errors. The password is an integer from 0 to 999999, which is easy to brute-force, and its default value is, of course, zero. The message authentication code (MAC) uses reversible operations, making it easy to analyze network traffic and, if necessary, recover the password through it. SSH access is available to root and zkteco users whose passwords could be recovered through accessing the device memory.

Device hijacking

The manufacturer provides the ability to access user data remotely, download photos, upload new users, and so on. Given the insecure implementation of the proprietary protocol, this creates a risk of personal data leakage, including biometrics. Threat actors can also add third parties to the database and exclude legitimate employees.

On top of that, errors in processing protocol commands give attackers even more options, such as injecting Unix shell system commands into image processing commands and reading arbitrary system files on the terminal, right down to the password-containing /etc/shadow.

What’s more, buffer overflow vulnerabilities in the firmware update command allow arbitrary code execution on the device. This creates attractive opportunities for attackers to expand their presence in the network. Since the biometric terminal will have no EDR agent or other security tools, it’s well suited for reconnaissance operations and routing traffic between compromised devices — if, of course, the terminal itself is connected to the internal network without additional restrictions.

How to reduce the risks of attacks through biometric terminals

ZKTeco devices are used worldwide under different brand names. If the devices in the illustration look like those in your office, it’s worth updating the firmware and scrutinizing the settings to make them more secure. Either way, various flaws in biometric terminals need to be taken into account regardless of the specific manufacturer. We recommend the following measures:

Choose a biometric terminal supplier carefully. Conduct preliminary analysis of previously known vulnerabilities in its equipment and the time taken to eliminate them. Request information about the supplier’s software engineering practices, giving preference to manufacturers that use a secure development lifecycle (SDL). Also request a detailed description of how information is stored, including biometrics.
Master the equipment settings and use the most secure configuration. We recommend disabling unnecessary and insecure authentication methods as well as unused services and features. Change all default credentials to strong and unique passwords for all biometric terminal administrators and users.
Physically block unnecessary connectors and interfaces on the terminal to eliminate certain attack vectors.
Include terminals in update and vulnerability management processes.
Isolate the network. If terminals are connected to the local network and linked to a management server, we recommend moving them to a separate physical or virtual subnet (VLAN) to rule out access to terminals from regular computers and servers, and vice versa. To configure access, we advise using a privileged access workstation isolated from regular network activity.
Consider telemetry from terminals as a source of information for the SIEM system and other deployed monitoring tools.

Kaspersky official blog – ​Read More

While investigating a cybersecurity incident, Kaspersky’s experts discovered new ransomware they’ve dubbed “ShrinkLocker”. An interesting feature of this malware is that its creators artfully use the built-in capabilities of Windows to lock down computers the malware has infected. In particular, ShrinkLocker uses the standard full-disc encryption utility BitLocker to block access to the data.

What makes ShrinkLocker dangerous?

Like most ransomware today, ShrinkLocker encrypts the victim’s local drives to block access to their contents. What it essentially does is activate a standard security feature — BitLocker.

ShrinkLocker shrinks the computer’s drive partitions by 100 megabytes — hence its name — and uses the freed-up space to create a boot partition for itself. While it’s at it, it disables every BitLocker key-recovery mechanism, and sends the key that was used for the drives’ encryption to the attacker’s server.

After the user restarts the computer, they’re presented with the standard BitLocker password prompt. Since the user is now unable to start the system, ShrinkLocker changes the labels of all system drives to the attacker’s email address instead of leaving a ransom note.

How ShrinkLocker works

ShrinkLocker is implemented as a complex VBScript. It starts by gathering information about the operating system — primarily, its version. If the script finds that it’s running on Windows 2000, XP, 2003, or Vista, it shuts down. For newer editions of Windows, it runs parts of its code that are optimized for the relevant operating system.

Next, it runs preparatory operations on the local drives as mentioned above, and modifies several registry keys to configure the system for running BitLocker smoothly with the settings that the attacker requires.

Then it disables and removes all default BitLocker protectors to prevent key recovery, and enables the numerical password-protector option.

The script then generates this password and initiates encryption of all local drives using the newly created password. After this, ShrinkLocker sends an HTTP POST request containing the password and system information to the attacker’s command-and-control server.

To mask the actual server address, the threat actor uses several trycloudflare.com subdomains. This is a legitimate domain owned by CloudFlare and designed for website developers to test website traffic tunneling capabilities.

In its final stages, ShrinkLocker covers its tracks by removing its files from the drive, clearing Windows PowerShell logs, and so on. Finally, the script restarts the system.

If the user tries choosing a recovery option while the machine is booting up, they get a message stating that no BitLocker recovery options are available.

Regarding the geographical distribution of infections, our researchers have observed ShrinkLocker and its modifications in Indonesia, Jordan, and Mexico. You can find more details about the ShrinkLocker modus operandi in our report on Securelist.

How to protect yourself from ShrinkLocker

Here are some tips for how to protect against ShrinkLocker and other ransomware threats:

Apply the principle of least privilege. In particular, users should not be given permissions to modify the registry or enable full-volume encryption.
Enable traffic monitoring. In addition to HTTP GET requests, it’s also helpful to log HTTP POST. In case of infection, requests to the attacker’s C&C server may contain passwords and keys.
Monitor events associated with VBS and PowerShell execution. Save scripts and commands you discover to external storage, as the malware may delete your local logs.
Back up your data regularly. Use offline storage for backups and verify their integrity.
Use a reliable security solution on all corporate devices. For example, Kaspersky Endpoint Security for Business detects ShrinkLocker with the verdicts Trojan.VBS.SAgent.gen, Trojan-Ransom.VBS.BitLock.gen, and Trojan.Win32.Generic.
Use EDR (Endpoint Detection and Response) solutions to monitor suspicious activity on your corporate network.

Kaspersky official blog – ​Read More