As cybersecurity threats grow more sophisticated, collaboration becomes a cornerstone of effective defense strategies. This is where MISP, an open-source threat intelligence sharing platform, comes into play.  

Recognizing its value, we are excited to announce the launch of our own MISP instance, enabling users to access and use indicators of compromise (IOCs) from ANY.RUN’s Threat Intelligence Feeds. 

What is MISP? 

MISP, which stands for Malware Information Sharing Platform, is a free, open-source platform designed to facilitate the exchange, storage, and correlation of threat intelligence data. MISP lets organizations and researchers: 

• Exchange critical data points to identify cyber threats. 
• Share signals or attributes indicating the compromise of information systems. 
• Automate the process of data sharing and find correlations between threat data. 

Benefits of ANY.RUN’s MISP Instance 

With ANY.RUN’s MISP instance, you can: 

1. Access ANY.RUN’s TI Feeds 

Receive a direct stream of the latest malicious IPs, URLs, domains, ports, file names, and hashes. These are extracted from public malware and phishing samples, including ones not found elsewhere, submitted and analyzed in ANY.RUN’s Interactive Sandbox by security professionals worldwide. IOCs are pulled from different sources, including network activities and malware configurations. 

2. Integrate It with Your Security Tools via API 

Connect your own monitoring and triage tools and systems, such as SIEM/XDR solutions, to ANY.RUN’s MISP instance via API. 

3. Improve Threat Detection  

Correlate and enrich your IOCs with ANY.RUN’s to develop a more comprehensive understanding of the threat landscape. 

4. Generate IDS Rules 

Export indicators (attributes) from ANY.RUN’s MISP instance in NIDS-compatible formats and import them in your detection tools like IDS/IPS or NGFW to improve network security of your organization and ensure proactive defense against current threats. 

5. Create Custom Workflows 

Leverage ANY.RUN’s indicators in your automated threat analysis workflows. 

6. Synchronize MISP Instances 

Synchronize your MISP instance with ANY.RUN’s to get relevant threat data. 

7. Visualize Threat Intelligence Data

Ensure a more convenient view of relevant threats by visualizing ANY.RUN’s TI Feeds data. 

8. Enrich with Your Threat Data 

Add your IOCs to the ones provided by ANY.RUN to gain a better picture of the threats at hand.

How to Integrate with ANY.RUN’s MISP Instance 

To get started with ANY.RUN’s MISP instance, simply contact our team via this page. 

You can test MISP feeds by getting a free demo sample here. 

About ANY.RUN  

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

Get a 14-day free trial of ANY.RUN’s Threat Intelligence service →

The post Access and Use ANY.RUN’s TI Feeds via MISP appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

As long as we’ve had the internet, users have tried to obfuscate how and what they are connecting to. In some cases, this is to work around restrictions put in place by governments or a desire to access content that is not otherwise available in a given region.

This is why technologies like VPNs and The Onion Router (TOR) become popular: They allow users to easily access content without exposing their IP address or location. These technologies are intended to protect users and information and have done a good job of doing so. However, adversaries have taken notice and are using proxy networks for malicious activities.

Proxy Chain Services

It is important to distinguish the different proxy chain services, as there are legitimate reasons for some of them to exist. From a privacy/defender point-of-view, they can be split into the following groups:

• VPN and TOR: These services provide the user anonymity, but the defender can, for the most part, determine that it’s receiving requests from these networks. As such, there is no expectation that the origin of the connection is the exact same as the user’s physical location. The user has no control of the path or exit node location. 
• Commercial residential services: These provide anonymity to users, while at the same time allowing them to choose the exit point. These services do not provide any clues to the defender about the nature of the connection. 
• Malicious proxy services: Threat actors use these networks to hide their location and choose their exit node. These are set up to be used by malicious operators from multiple sources. They can take two shapes: The nodes are installed on leased servers from different providers in different regions, or their nodes can be compromised edge devices that bounce connections in chains.

The first group has a clear legitimate use case, and the second has been advertised as a means to measure marketing engagement. However, threat actors can also use them without the bandwidth owner understanding what is at risk. The third case is clear: The networks are built to be rented for distributed denial-of-service (DDoS) attacks or access to be sold so other actors can anonymize their activities.

History

Leveraging proxy networks for malicious purposes was something we first stumbled on with our research into Honeygain. This was one of the first times we saw technologies like proxyware being abused maliciously. 

Proxyware is a type of technology that uses agents installed by users to act as proxies for other users. The users installing these agents are typically compensated for adding their node to the proxy network. Criminals stumbled upon this quickly and began to weaponize and monetize it, allowing them to benefit from the anonymity these technologies provide since it traces back to a random computer in a random location. At the time, the focus was purely criminal in nature, but state-sponsored groups have been leveraging TOR and VPNs for decades to launch their attacks, typically dropping out of a VPN near the target.

State-sponsored groups also realize that TOR and VPNs have limitations and could potentially expose their operations, so they needed something more opaque and less traceable. Enter VPNFilter.

VPNFilter was the first large-scale proxy network leveraged by state-sponsored actors, in this case Russia. This completely changed how proxy networks were operated and would set the tradecraft for state-sponsored proxy networks for the next several years. The most unique aspect of VPNFilter was the targeting: small office and home office (SOHO) routers. 

The network was made up of SOHO routers that were being compromised with malicious firmware providing a variety of capabilities, including interception and proxy capabilities. 

This was also a fairly significant botnet, consisting of some 500,000 devices that created a massive network from which to launch attacks without repercussions. Fortunately, we worked with affected vendors, and they resolved many of the issues that were being exploited, both vulnerability and otherwise. 

This wasn’t the last time we saw Russian-aligned actors leveraging these types of botnets. A few years later, Cyclops Blink was uncovered. Another Russian actor controlled a proxy network that again primarily consisted of consumer devices. 

The targeting of consumer devices for this type of activity has become the focus of state-sponsored groups’ foray into this space. They also make excellent targets, since many users leave default configurations in place and rarely think to update their devices. Fortunately, post-VPNFilter, many vendors have switched to automatic updates, allowing for more frequent patching. This has resulted in state-sponsored groups widening their targeting. 

Today, we see not just SOHO routers, but also NAS and a variety of IoT devices being targeted and added to these networks. This problem has just gotten worse in the past several years.

State of the Art

As recently as September, the FBI took down a botnet associated with Chinese hacking activities. This was just the latest in a spate of attacks originating from proxy networks. This activity has been largely associated with Volt Typhoon by the U.S. Government, with a broader attribution of China-linked activities in the recent FBI takedown.

Currently, there are several proxy-based networks, with a focus on SOHO devices (e.g., routers, NAS, etc.) and a variety of IoT components (e.g., security cameras) being compromised and added to a botnet that, in some ways, mirrors Mirai botnet activities. 

The basic operating model for these botnets is that they are peer-to-peer, meaning there is no discernable routing. This model provides a sophisticated network of devices to obfuscate the true origin of an attack, and in many circumstances, allows the attacker to appear in close proximity to the victim, including coming from geographically adjacent residential networks. 

The attacks originating from these networks have been tied to espionage and the targeting of critical infrastructure in the U.S. and globally. Most countries are concerned with this escalation, and it has the attention of the majority of vendors in this space. 

These networks have also grown with staggering efficiency, with new nodes being added constantly as other nodes fall off and need to be compromised again. Based on reporting, the majority of these infections are using N-Day vulnerabilities or weak credentials to gain access, something we’ve seen repeatedly out of botnets like Mirai for the last decade. The major difference is that Mirai is used to conduct DDoS attacks, and the new iterations are being used to launch state-sponsored attacks with anonymity.

Network Resiliency Coalition

The repeated use of N-Day vulnerabilities and weak credentials ties into the work that Cisco has been doing for some time related to old and outdated networking equipment and the risks they introduce. The Network Resiliency Coalition is one of the projects aimed at trying to resolve this difficult problem. Anonymization networks’ reliance on networking equipment, specifically exploiting known vulnerabilities, adds more weight to the importance of this effort. By working with industry peers, Cisco is trying to help remove many of the systems that are being abused in these attacks by working with vendors to ensure proper patching is provided to mitigate these known vulnerabilities, in a timely manner.  

More projects like this that encompass the IoT industry and the non-edge SOHO appliances like NAS devices would also have a contribution to the fight against anonymization networks. This combined with better credential management, most notably ensuring that default credentials are complex and unique, could make a huge impact on how successful these networks are in continuing to grow. Vendors are working to try and resolve some of these weaknesses, but it also is paramount for defenders to take note.

Impact on Defenders

This continued focus by state-sponsored groups to leverage these networks presents problems for defenders. Attacks from these groups are likely to be coming from residential networks, potentially even from residential networks in the same cities and countries as your organization operates, making identification and attribution increasingly difficult. 

Organizations need to realize that attacks can come from anywhere, even the same IP space that your employees connect to their VPNs, so plan accordingly. 

This is further complicated by the increased focus by state-sponsored groups on the use of legitimate credentials. If you have a connection coming from the same IP space as your employees, using legitimate credentials organizations have little hope to stop it. This is where the increased focus on identity comes into play — organizations need to start taking additional steps to be able to distinguish between the illegitimate and legitimate use of credentials, and that ties back to behavior. 

Increasingly, organizations should be looking at users’ behavior when it comes to connections.

• Are they using their typical device type? (e.g., Windows desktop/MacOS laptop)
• Are they logging on during their typical hours? (e.g., 9-5 M-F)
• Are there other managed devices in proximity?
• Are they using their managed device?

This last point is a critical one. For organizations particularly concerned with credential abuse, managed device access restriction may be the best option. 

This ensures that only managed devices can connect to corporate VPNs through technologies like certificates. 

The downside to this approach is that it’s expensive, and for many organizations not practical, but for those with the budgets and the concern, it’s a needed escalation beyond just multi-factor authentication (MFA). 

You may have noticed we haven’t mentioned MFA until now. But that’s because in 2024, it’s assumed you’ve already rolled out MFA for medium to large enterprises. It is no longer an optional security feature. 

Defenders need to adjust for the state-sponsored threats they will be facing in 2024 and beyond. This means adding more identity capabilities in the near term and looking at additional security protections like managed device-only access in the future.

Cisco Talos Blog – ​Read More

Overview

The Cybersecurity and Infrastructure Security Agency (CISA) added a critical vulnerability, CVE-2024-49138, to its Known Exploited Vulnerabilities (KEV) catalog based on evidence that this flaw is being actively exploited. The vulnerability, identified in the Microsoft Windows Common Log File System (CLFS), is a heap-based buffer overflow issue that has the potential to allow attackers to escalate privileges on vulnerable systems. As part of Microsoft’s Patch Tuesday release, this flaw was patched alongside other critical vulnerabilities.

CVE-2024-49138 is a heap-based buffer overflow vulnerability in the CLFS driver. This driver is used by both user-mode and kernel-mode software in Windows for general-purpose logging. This vulnerability affects several versions of Microsoft Windows operating systems, including Windows 10 and 11, as well as several Windows Server versions.

Heap-based buffer overflow vulnerabilities, like CVE-2024-49138, are common attack vectors for cybercriminals. These flaws can result in system crashes, denial of service, or even allow malicious actors to execute arbitrary code. In the case of CVE-2024-49138, it allows attackers to escalate their privileges to the SYSTEM level, enabling them to take full control of a compromised system.

This issue was actively exploited in the wild before it was addressed by Microsoft, which makes it particularly dangerous. The flaw has been assigned a CVSSv3.1 score of 7.8 (high severity).

CVE-2024-49138 Impact on Affected Systems

The vulnerability affects a broad range of Windows operating systems. Specifically, it impacts Windows 11 versions 22H2, 23H2, and 24H2 for both x64 and ARM64-based systems. In addition, Windows 10 versions from 1607 to 22H2 are vulnerable, including x64, ARM64, and 32-bit systems.

Furthermore, several Windows Server versions are also impacted, spanning from 2008 to 2025. This includes versions such as Windows Server 2012, 2016, 2019, and 2022, with both Core and full installations being affected. These widespread vulnerabilities increase the potential for exploitation across various systems in both personal and enterprise environments.

Active Exploitation and Patch Release

Given that CVE-2024-49138 was actively exploited before the patch was released, Microsoft’s Patch Tuesday update for December 2024 was critical in addressing the issue. Microsoft rated this vulnerability as important, reflecting the immediate threat posed to organizations and users who have not yet applied the patch.

An official security update was issued for all affected systems, and users are encouraged to install it as soon as possible to mitigate the risk of attack. CISA’s inclusion of CVE-2024-49138 in its Known Exploited Vulnerabilities Catalog highlights the growing focus on vulnerabilities that attackers are actively targeting.

By cataloging such issues, CISA aims to increase awareness and ensure that organizations prioritize the application of patches for vulnerabilities that are under active exploitation.

Recommendations and Mitigation Strategies

To protect systems from CVE-2024-49138, organizations, and individual users should follow these best practices:

1. The Microsoft Patch Tuesday update for December 2024 addresses CVE-2024-49138. Ensure that all affected systems are updated with the latest patches. Microsoft provides an official patch link for direct updates.
2. Implement a consistent patch management strategy to ensure all vulnerabilities are patched as soon as updates are available. Automating patching processes can reduce the risk of missed updates, especially for critical vulnerabilities like CVE-2024-49138.
3. Organizations should use Security Information and Event Management (SIEM) systems to detect unusual activities associated with privilege escalation. Monitoring network traffic and system logs can help identify attempts to exploit CVE-2024-49138 before damage occurs.
4. An effective incident response plan is essential. Organizations should regularly test their response procedures for various vulnerabilities, including those that target Microsoft Windows components like the CLFS driver.
5. Users running older, unsupported versions of Windows should prioritize upgrading to supported versions to reduce their exposure to vulnerabilities such as CVE-2024-49138.

Conclusion

CISA’s inclusion of this flaw in its Known Exploited Vulnerabilities Catalog emphasizes the urgency of applying the December 2024 Patch Tuesday update. Organizations should adopt automated patch management, use SIEM systems for early detection, and have an incident response plan in place. Users running outdated Windows versions should upgrade to reduce vulnerability.

The post CISA Adds CVE-2024-49138 to the Known Exploited Vulnerabilities Catalog, Urgency for Microsoft Users appeared first on Cyble.

Blog – Cyble – ​Read More

Editor’s note: The current article is authored by Mostafa ElSheimy, a malware reverse engineer and threat intelligence analyst. You can find Mostafa on X and LinkedIn. 

In this malware analysis report, we will delve into Nova, a newly discovered fork of the Snake Keylogger family. This variant has been observed employing even more sophisticated tactics, signaling the continued adaptation and persistence of the Snake malware family in the cybersecurity landscape. 

Overview of Snake Keylogger 

Snake Keylogger, a .NET-based malware first identified in November 2020, is infamous for its credential-stealing and keylogging capabilities.

Read in-depth analysis of Snake Keylogger

It primarily spreads through phishing and spearphishing campaigns, where malicious Office documents or PDFs are used to deliver downloader scripts via PowerShell. Once executed, Snake Keylogger captures keystrokes, steals saved credentials, takes screenshots, and extracts clipboard data. 

As of 2024, Snake Keylogger has continued to evolve, adopting advanced evasion techniques such as process hollowing and heavily obfuscated code to avoid detection.  

This variant uses a suspended child process to inject its payload, which makes it more difficult for security software to identify and neutralize. Furthermore, reports indicate that Snake Keylogger has grown more prevalent, with significant spikes in zero-day detections, suggesting its ongoing threat to both personal and corporate cybersecurity. 

Technical Analysis Using ANY.RUN Sandbox 

Let’s run a sandbox analysis session using ANY.RUN’s Interactive Sandbox to discover the technical details of this malware.  

View analysis session 

In the HTTP Requests tab, we can see that Nova sends HTTP Requests to hxxp[://]checkip[.]dyndns[.]org/ to get the IP of the victim device: 

In DNS requests tab, Nova makes DNS requests to reallyfreegeoip[.]org to get the country name of the victim device: 

Unpacking 

Nova keylogger uses a protector written in AutoIt. There are several ways to unpack it: 

1. Decompiling the executable to AutoIt script (.au3) 

2. Executing the sample and letting it unpack itself in the memory, then dumping the process. This can be done with the help of the following tools: 

• Sandbox 
• Unpacme
• Pe-sieve 

Learn to unpack malware

According to Unpacme, the unpacked sample is obfuscated using the Net Reactor Obfuscator: 

Exeinfo also confirms this: 

The presence of numerous empty functions strongly suggests obfuscation, which aligns with the tools’ analysis. 

To address this, we can use NETReactorSlayer for deobfuscation. 

NETReactorSlayer performed exceptionally well in this task, successfully deobfuscating the sample. 

Deep Analysis 

Nova is capable of extracting sensitive data from a wide range of sources, including:

• Browsers: Chrome, Brave, Opera, Firefox, Edge, etc.
• Emaial Clients: Outlook, Foxmail, Thunderbird.
• FTP Clients: Filezilla.

It can also retrieve and decode the Windows product key.

Let’s take a closer look at these functionalities to understand their implications and the depth of Nova’s capabilities. 

Extracting and Decrypting Outlook Passwords №

Nova performs the following steps to extract and decrypt Outlook passwords: 

1. Initialization 

• Creates a list to store recovered account details. 
• Prepares an array of strings representing the password types to search for in the Windows registry. 

2. Accessing registry keys 

Nova opens the following registry keys, which are known to store Outlook profile information: 

• Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676 
• Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676 
• Software\Microsoft\Windows Messaging Subsystem\Profiles\9375CFF0413111d3B88A00104B2A6676 
• Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676 

3. Iterating through registry keys and subkeys 

• Nova scans the registry keys and their subkeys, checking for entries containing email or password data. 
• If such entries are found, Nova attempts to decrypt the password using the decryptOutlookPassword method. 

4. Decrypting passwords 

The decryptOutlookPassword method performs the following actions: 

• Takes the encrypted Outlook password as a byte array. 
• Removes the first byte from the array. 
• Decrypts the remaining data and converts it to a readable string. 
• Strips any null characters from the resulting string before returning it. 

5. Retrieving account details 

It retrieves the email value and converts it to a byte array using GetBytes. 

Then, it retrieves the SMTP server value, if available and adds the recovered account details to the list. 

Extracting and Decrypting Browser Login Information 

Various functions exist for extracting browser login credentials. For this analysis, we will focus on Chrome_Speed, which targets Google Chrome’s saved login data. 

1. Locating the Login Data file 

Chrome_Speed constructs the path to the Login Data SQLite file, where Chrome stores saved login credentials. Then verifies the existence of the Login Data file before proceeding. 

2. Retrieving Login entries 

It loops through each login entry, retrieving the origin_url, username_value, and password_value. 

3. Decrypting passwords 

If passwords are stored in Version 10 format, it uses the master key for decryption. For older formats, an alternative decryption method, Decrypttttt, is employed. 

Key Methods Analyzed 

Let’s analyze GetMasterKey and Decrypttttt methods: 

1. GetMasterKey 

GetMasterKey retrieves and decrypts the master key used by Google Chrome to protect saved passwords. It reads the encrypted master key from the Local State file located in the Chrome user data directory, then decrypts it for further use. 

The process begins by constructing the path to the Local State file, which stores the encrypted master key. 

It first checks for the existence of the Local State file; if the file is absent, the method returns null. 

Upon confirming the file’s presence, the contents are read, and a regular expression is employed to extract the encrypted master key. 

The method iterates through the matches to convert the encrypted key from a Base64 string into a byte array. 

Notably, a new byte array is created that excludes the first five bytes of the original array, as these bytes do not form part of the actual key. 

Finally, the method attempts to decrypt the trimmed key using the ProtectedData.Unprotect method, which is designed to decrypt data that has been secured with the ProtectedData.Protect method. 

The Unprotect method is a function that decrypts data protected by the Windows Data Protection API (DPAPI). It first checks if the input data is valid and compatible with NT-based systems.  

The method then pins the memory of the encrypted data and any optional entropy to avoid issues during decryption.  

It calls CryptUnprotectData to decrypt the data and handles errors by throwing exceptions when needed.  

Finally, it clears sensitive data from memory before releasing resources. 

2. Decrypttttt 

Decrypttttt method is a function that decrypts a byte array using the Windows Data Protection API (DPAPI). 

It begins by initializing data structures to hold the encrypted data and the decrypted output. 

The method pins the input byte array in memory to prevent the garbage collector from moving it during decryption. 

After setting up the necessary structures, it calls CryptUnprotectData API to perform the decryption. 

Once the data is decrypted, the method copies the output into a new byte array, converts it to a string, and removes any trailing null characters. 

Finally, it returns the decrypted string, ensuring proper handling of sensitive data throughout the process. 

Let’s get back to Chrome_Speed function  

It combines the URL, username, and password into a formatted string: 

"rn============X============rnURL: " 

    "rnUsername: " 

    "rnPassword: " 

    "rnApplication: Google Chromern=========================rn "

The formatted string is appended to a collection of stored credentials for further use or exfiltration. 

Extracting Windows Product Key 

The process of extracting the Windows product key involves accessing the system registry and decoding the DigitalProductID. Here’s a detailed breakdown: 

• Accessing the registry 

First it opens “Software\Microsoft\Windows NT\CurrentVersion” registry key 

• Fetching DigitalProductID 

Then, the DigitalProductID is fetched from the registry as a byte array. This ID is used to generate the Windows product key. 

• Extracting relevant bytes 

A specific portion of the DigitalProductID is copied into a new byte array. 

The product key is derived from bytes starting at index 52 in the sourceArray. 

• Decoding the product key 

The outer loop runs 25 times (from 0 to 24) to form the product key. The inner loop processes each byte in reverse (from 14 to 0) to decode and generate the corresponding characters. 

• Formatting the product key 

The method returns the formatted product key as a string (e.g., XXXXX-XXXXX-XXXXX-XXXXX-XXXXX) 

Getting Victim’s Info  

The process gathers key information about the victim, including: 

• IP Address 
• Country 
• PC Name 
• Date and Time 

It gets the victim’s IP by making a request to: hxxp[://]checkip[.]dyndns[.]org/ 

The country information is retrieved by querying:  hxxps[://]reallyfreegeoip[.]org/xml/ 

Data format 

The collected information is structured in a formatted string for further use: 

Getting Clipboard Data 

The process of extracting data from the clipboard involves the following steps: 

• IsClipboardFormatAvailable checks if the clipboard contains text in Unicode format 

• OpenClipboard opens the clipboard to allow examination and retrieval of data 

• GetClipboardData retrieves the data handle from the clipboard in the specified format 

Exfiltration 

Nova supports three data exfiltration methods: FTP, SMTP, or Telegram, depending on the configuration set by the malware author. 

It compares the UltraSpeed.QJDFjPqkSr value against specific flags: 

• “#FTPEnabled”: If true, data is exfiltrated via FTP. 
• “#SMTPEnabled”: If true, data is exfiltrated via SMTP. 
• “#TGEnabled”: If true, data is exfiltrated via Telegram. 

In this particular sample, the exfiltration method is Telegram: 

As we see, there are no credentials provided for SMTP and FTP servers:

Telegram Exfiltration 

The code responsible for exfiltration through Telegram includes details about the bot and its endpoint for sending data: 

Telegram API endpoint: hxxps[://]api[.]telegram[.]org/bot7479124552:AAELHYVLYxHEQdxzK-H17KRix-YKXifzKCI 

JSON Responses from the Telegram Bot API 

The provided images showcase JSON responses retrieved from the Telegram Bot API. These responses contain detailed information about bots that are directly associated with the NOVA family of malware. 

Code Reference to “NOVA” 

The malware’s source code explicitly mentions “NOVA”, reinforcing its attribution to this specific malware family. 

Conclusion 

The Nova variant of the Snake Keylogger represents a significant evolution of its predecessor, with advanced evasion techniques and a broader array of data exfiltration capabilities.  

Written in VB.NET, Nova leverages obfuscation methods such as Net Reactor Obfuscator and utilizes process hollowing to evade detection, making it a more persistent and stealthy threat. Through its sophisticated techniques, including credential harvesting from a wide variety of browsers, email clients, and other sensitive data, Nova demonstrates its ability to target both personal and corporate systems effectively. 

The malware is capable of extracting a wide range of valuable information, including saved passwords, credit card details, and system keys, from both browsers and email clients. In addition, its ability to gather data from a victim’s clipboard and exfiltrate it via multiple channels—such as FTP, SMTP, or Telegram—demonstrates its adaptability and versatility. 

While the use of Telegram as the exfiltration method in this specific sample shows a shift towards more covert communication, the ability to switch exfiltration methods allows the malware to avoid detection by security systems that might block certain channels. The malware’s integration with popular tools like Telegram also indicates its use in large-scale, automated cybercrime activities, making it a serious threat to organizations and individuals alike. 

About ANY.RUN

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

With ANY.RUN you can: 

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

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

IOCs

Nova:  

68f5247bd24e8d5d121902a2701448fe135e696f8f65f29e9115923c8efebee4  

Dropped files 

C:UsersadminAppDataLocalTempfondaco afb1dae7a6f2396c3d136e60144b02dd03c59ab10704918185d12ef8c6d7ec93 

C:UsersadminAppDataRoamingMicrosoftWindowsStart MenuProgramsStartupneophobia.vbs 66dbb9c8deadea9f848b1b55405738d8a65a733c804f1444533607c20584643e 

C2 URL

hxxps://api[.]telegram[.]org/bot7479124552:AAELHYVLYxHEQdxzK-H17KRix-YKXifzKCI/sendDocument 

Bot Token

7479124552:AAELHYVLYxHEQdxzK-H17KRix-YKXifzKCI 

Chat ID 

5679778644 

MITRE ATT&CK Techniques

The post Analysis of Nova: A Snake Keylogger Fork appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

From the perspective of information security, wireless networks are typically perceived as something that can be accessed only locally — to connect to them, an attacker needs to be physically close to the access point. This significantly limits their use in attacks on organizations, and so they are perceived as relatively risk-free. It’s easy to think that some random hacker on the internet could never simply connect to a corporate Wi-Fi network. However, the newly emerged Nearest Neighbor attack tactic demonstrates that this perception is not entirely accurate.

Even a well-protected organization’s wireless network can become a convenient entry point for remote attackers if they first compromise another, more vulnerable company located in the same building or a neighboring one. Let’s delve deeper into how this works and how to protect yourself against such attacks.

A remote attack on an organization’s wireless network

Let’s imagine a group of attackers planning to remotely hack into an organization. They gather information about the given company, investigate its external perimeter, and perhaps even find employee credentials in databases of leaked passwords. But they find no exploitable vulnerabilities. Moreover, they discover that all of the company’s external services are protected by two-factor authentication, so passwords alone aren’t sufficient for access.

One potential penetration method could be the corporate Wi-Fi network, which they could attempt to access using those same employee credentials. This applies especially if the organization has a guest Wi-Fi network that’s insufficiently isolated from the main network — such networks rarely use two-factor authentication. However, there’s a problem: the attackers are on the other side of the globe and can’t physically connect to the office Wi-Fi.

This is where the Nearest Neighbor tactic comes into play. If the attackers conduct additional reconnaissance, they’ll most likely discover numerous other organizations whose offices are within the Wi-Fi signal range of the target company. And it’s possible that some of those neighboring organizations are significantly more vulnerable than the attackers’ initial target.

This may simply be because these organizations believe their activities are less interesting to cyberattack operators — leading to less stringent security measures. For example, they might not use two-factor authentication for their external resources. Or they may fail to update their software promptly — leaving easily exploitable vulnerabilities exposed.

One way or another, it’s easier for the attackers to gain access to one of these neighboring organizations’ networks. Next, they need to find within the neighbor’s infrastructure a device connected to the wired network and equipped with a wireless module, and compromise it. By scanning the Wi-Fi environment through such a device, the attackers can locate the SSID of the target company’s network.

Using the compromised neighboring device as a bridge, the attackers can then connect to the corporate Wi-Fi network of their actual target. In this way, they get inside the perimeter of the target organization. Having achieved this initial objective, the attackers can proceed with their main goals — stealing information, encrypting data, monitoring employee activity, and more.

How to protect yourself against the Nearest Neighbor attack

It’s worth noting that this tactic has already been used by at least one APT group, so this isn’t just a theoretical threat. Organizations that could be targeted by such attacks should start treating the security of their wireless local area networks as seriously as the security of their internet-connected resources.

To protect against the Nearest Neighbor attack, we recommend the following:

• Ensure that the guest Wi-Fi network is truly isolated from the main network.
• Strengthen the security of corporate Wi-Fi access — for instance, by using two-factor authentication with one-time codes or certificates.
• Enable two-factor authentication — not only for external resources but also for internal ones, and, in general, adopt the Zero Trust security model.
• Use an advanced threat detection and prevention system, such as Kaspersky Next XDR Expert.
• If you lack highly qualified in-house cybersecurity specialists, make use of external services such as Managed Detection and Response and Incident Response.

Kaspersky official blog – ​Read More