The turbulent waters of the internet of things (IoT) will soon become more navigable — thanks to the recently adopted ISO/IEC 30141 standard, which defines reference architecture for IoT solutions. For our part, Kaspersky has been actively involved in the development of trust principles for IoT devices as laid out by the ISO/IEC TS 30149:2024 specification. Let’s use this example to explore why we need standards at all, what can be standardized in the IoT, and why IoT devices and their manufacturers must prove that they’re worthy of consumer trust.

Why we need standards

If you’re already familiar with the basic principles of standardization in electronics, feel free to skip ahead to the next section.

When you plug your smartphone’s charger into a hotel wall socket while on vacation, dozens of international standards are invisibly at play. Chargers are manufactured in accordance with IEC 60335-1:2020, which deals with the electrical safety of household appliances; plug shapes are governed by IEC 60906-1:2009 and its derivatives (such as CEE 7/16); and the supplied voltage itself is regulated by IEC 60038:2009+A1:2021. Widespread standardization has greatly simplified our lives: most countries worldwide use the same types of electrical appliances, barcodes on product packaging, and units of weight, length, and speed. In turn, unified approaches to controlling harmful substances in products, insulating and earthing household appliances, medication dosages, and traffic-sign coloring have massively improved safety and streamlined goods’ certification and testing.

The International Electrotechnical Commission (IEC) summarizes the benefits of standardization as follows. Standards:

Enable different products to interoperate
Are used in testing and certification to verify that manufacturers deliver on their promises
Contain technical details for inclusion in country-specific regulations
Simplify international trade

There are quite a few standardization bodies in existence — some regional, some industrial, some technical-field-specific. Besides the aforementioned IEC, there are, for example, the Internet Engineering Task Force (IETF) — responsible for developing internet standards; the American National Standards Institute (ANSI) — which issues standards for the US market; and the most universal of them all — the International Organization for Standardization (ISO). Where their areas of responsibility overlap, these bodies often collaborate to develop common recommendations. For example, electrical engineering standards are typically prefixed ISO/IEC.

Note that manufacturer compliance with any standard is voluntary. However, individual countries may prohibit the sale of, say, electrical appliances that don’t comply with local or international standards.

Standards for smart technology

Standards can describe not only the features of a finished product, but also how to manufacture it — addressing both hardware and software aspects. Therefore, the recently adopted ISO/IEC 30141:2024, which describes the architecture of IoT-related devices and services, is a logical — and long overdue — addition to the standards portfolio. Standardization based on this specification addresses several pressing issues:

Wireless sensors and the hubs they interact with will use the same protocols so that equipment from different vendors can interoperate in homes and within companies.
Standardized internet communications for IoT devices will reduce user dependence on the manufacturer (vendor lock-in), and eliminate situations where a server shutdown turns your smart home into a pumpkin — Cinderella-style.
A standardized approach to IoT-solution development will enable the use of more mature implementations of communication protocols. Furthermore, standard outline mandatory security measures and their implementation in both hardware and software aspects of devices. All of this will cut the number of IoT devices harboring glaring security issues (1, 2, 3, 4).

An important complement to IEC 30141 was the ISO/IEC TS 30149:2024 specification, released in May, which lays out principles for IoT trustworthiness. The document answers the question of how to prove that an IoT device is secure (rather than just relying on the vendor’s claims) — and Kaspersky helped develop it.

Five aspects of verifiable security

The key concept of the document is trustworthiness, which differs from trust. Trust is based on assumptions, some of which may be true and based on observable properties (“made of metal”), while others may be unfounded (“doesn’t contain secret backup passwords”). According to the specification, trustworthiness is the verifiable ability to meet expectations. ISO/IEC TS 30149:2024 details how trust, trustworthiness, and risk correlate, and describes five aspects in which an IoT solution’s trustworthiness can be demonstrated. These are:

Safety
Security
Privacy
Resilience
Reliability

For each of these aspects, trustworthiness is ensured through specific approaches to system design and construction. The document provides best-practice templates for building IoT systems and ensuring trust in them — from threat-assessment methodologies for trust-related violations, to architectural solutions for trusted systems (for example, MILS).

What to expect from the IoT of the future

The adoption of standards alone won’t magically improve IoT security overnight. Old products already no longer comply, while for new ones compliance with standards needs to become a requirement of both national and international regulators. Manufacturers would then need to invest considerable time in developing new products that comply with these standards. That said, in a few years, we can expect significant improvements in the security of both industrial and consumer IoT devices. These should include simple yet effective measures — such as secure default settings, and long, pre-defined periods for update delivery. More complex yet crucial improvements should include the widespread adoption of secure-by-design approaches, plus standardized, publicly-verified communication protocols to make products less vulnerable. With these in place, experts would be able to more easily analyze the security of specific products thanks to better-documented system and protocol architecture. And the ultimate goal: consumers knowing for sure that the IoT devices they purchase are secure, reliable, and resilient to threats (both physical and cyber) throughout the entire lifecycle of those IoT devices.

Kaspersky official blog – ​Read More

The Cybersecurity and Infrastructure Security Agency (CISA) has added multiple vulnerabilities to its known Exploited Vulnerabilities (KEV) catalog. A total of six vulnerabilities have been identified across various products, including Zimbra Collaboration, Ivanti, D-Link, DrayTek, GPAC, and SAP. Notably, these vulnerabilities span a range of severity levels, from critical to medium, demanding immediate attention.

One of the most interesting entries is CVE-2024-45519, associated with Zimbra Collaboration. This critical vulnerability has been assigned a CVSS score of 9.8, indicating its severe nature. The issue arises from the postjournal service in specific versions of Zimbra, which may permit unauthenticated users to execute commands. 

This vulnerability was first analyzed by researchers from ProjectDiscovery, who demonstrated a Proof of Concept (PoC) exploit. On October 1, 2024, security researcher Ivan Kwiatkowski reported that mass exploitation of this vulnerability had commenced, with Cyble’s ODIN scanner revealing 35,315 internet-facing ZCS instances at the time of the advisory’s publication.

Another critical vulnerability highlighted is CVE-2024-29824 in Ivanti’s Endpoint Manager (EPM) 2022. This high-severity SQL Injection vulnerability allows an unauthenticated attacker within the same network to execute arbitrary code. Exploitation attempts have been noted by the Shadowserver Foundation, highlighting the urgency of patching this vulnerability, which carries a CVSS score of 8.8.

The advisory also discusses CVE-2023-25280, a critical OS injection vulnerability affecting D-Link devices. This flaw, which allows an attacker to manipulate system commands through insufficient validation of the ping_addr parameter.

Other Notable Vulnerabilities

Additionally, CVE-2020-15415 affects several models of DrayTek routers, allowing remote command execution via OS injection. With a CVSS score of 9.8, this vulnerability is deemed critical and must be addressed urgently. Cyble’s ODIN scanner indicated that 275,109 instances of affected routers are currently exposed, emphasizing the widespread risk.

Furthermore, CVE-2021-4043 represents a medium-severity vulnerability in the GPAC repository, which may lead to a denial-of-service (DoS) condition. Finally, CVE-2019-0344 in SAP Commerce Cloud also poses a critical risk due to unsafe deserialization, allowing arbitrary code execution with minimal authentication requirements.

The addition of these vulnerabilities to CISA’s KEV catalog is a clear indicator that threat actors are actively exploiting them. Organizations must recognize that vulnerabilities listed in the KEV catalog represent real-world risks, not just theoretical concerns. Failure to address these issues can lead to severe consequences, including data breaches, ransomware attacks, and privilege escalation.

Conclusion

CISA’s advisory highlights the urgent need for organizations to address vulnerabilities that have been identified and exploited in the wild. With the cyber threat landscape continuously evolving, timely patching and the adoption of better security practices are essential to safeguarding sensitive information and maintaining organizational integrity.

Recommendations and Mitigations

To combat these vulnerabilities effectively, organizations are urged to implement several key strategies:

Regularly apply the latest patches from official vendors for all software and hardware systems. Establish a routine for patch management, prioritizing critical updates.

Develop a comprehensive patch management process that encompasses inventory management, assessment, testing, deployment, and verification of updates. Automate where possible to improve efficiency.

Implement proper network segmentation to protect critical assets. This can be achieved through firewalls, VLANs, and strict access controls, effectively minimizing exposure to potential threats.

Maintain an updated incident response plan detailing procedures for detecting, responding to, and recovering from security incidents. Regularly test and refine this plan to ensure its effectiveness.

Proactively identify and phase out end-of-life products to minimize risk exposure. Organizations should prioritize timely upgrades or replacements for critical systems.

The post CISA Flags Multiple Critical Vulnerabilities Exposed Across Major Platforms appeared first on Cyble.

Blog – Cyble – ​Read More

Editor’s note: The current article is authored by Mohamed Talaat, a cybersecurity researcher and malware analyst. You can find Mohamed on X and LinkedIn.

In this malware analysis report, we take an in-depth look at how an undocumented loader called PhantomLoader has been used by attackers to distribute a rust-based malware known as SSLoad.

Overview

The PhantomLoader usually masquerades as a legitimate 32-bit DLL written in C/C++ for an antivirus software called 360 Security Total.

However, in this case, it was found disguising itself as “PatchUp.exe,” which is still a legitimate module of 360 Total Security. This loader has been used in recent attacks to deliver a new rust-based malware called SSLoad.

What makes PhantomLoader unique is that it was added to be part of a legitimate DLL or executable of a well-known software by binary patching the DLL or executable and adding a self-modifying technique. The latter decrypts an embedded code stub, which then decrypts and loads “SSLoad” into memory.

PatchUp.exe and legitimate module of 360 Total Security

Technical analysis

After analyzing the SSLoad sample in ANY.RUN’s sandbox, we observed that one distribution method for this malware involves phishing emails containing malicious Office documents. These documents initiate the infection chain.

The analysis session shows how the drop and execution of PhantomLoader occurs, after which it decrypts and runs SSLoad.

View the analysis session

Execution of Malicious Word document

After executing the malicious Word document, it became clear that a new process, “app.com,” was launched by “WINWORD.exe,” indicating that an embedded malicious macro had been executed. This resulted in the creation of the suspicious process. 

To better understand the infection chain, the macro was extracted and analyzed further.

Execution of Decoded XML String

In the ANY.RUN Script Tracer, it was observed that the malware loads an encoded XML string, which appears to be obfuscated using JScript. This encoding is used to disguise the malicious intent, making it more difficult to detect. 

Once loaded, the XML string is executed, triggering the next stage in the malware’s infection process.

Upon further investigation of the document’s macros, an Autoclose macro was found that reads an XML string from an XML file named “UserForm1.”

After analyzing the referenced form file, it became clear that the loaded XML string is encoded in JavaScript. This encoding serves as a protection measure designed by Microsoft to prevent unauthorized copying or alteration of VBScript or JavaScript code.

Using CyberChef, the JavaScript was decoded, revealing the underlying code used by the malware to continue the infection process. This provides clear insights into the next steps of the attack.

The JavaScript code decodes the next stage, PhantomLoader, using base64. It then places the decoded file in the user’s %TEMP% directory with the name “app.com” and starts it. 

First Loader: PhantomLoader

PhantomLoader disguises itself as a legitimate DLL module for the antivirus software 360 Total Security. This tactic allows it to remain undetected by both the system and users.

This is one of the rare cases where the malicious code runs before the main function is reached. This strongly suggests that the legitimate DLL module has been modified. A malicious routine is inserted before the main function, along with an encrypted stub. 

The malicious routine embedded within the DLL module first calculates the address of the encrypted code stub, which is hidden within the file. It then decrypts this stub using a XOR operation with a hardcoded key.

The encrypted code is located in the .text section of the DLL. It was disassembled by IDA, but the disassembled output appeared nonsensical, indicating that the code is indeed encrypted.

To further analyze the encrypted code in IDA, an IDAPython script was created to decrypt and patch the code in place.

The decrypted code stub begins by fetching the base address of “kernel32”, a core Windows system DLL that provides essential system functions. It then uses this base address to resolve the following function addresses by hash:

VirtualAlloc – Responsible for memory allocation.

LoadLibraryA – Loads libraries (DLLs) into memory.

GetProcAddress – Retrieves the address of functions or variables from the loaded DLLs.

The resolved functions are then used to load the decrypted next-stage loader, SSLoad, directly into memory.

Using the same key as before, it XOR decrypts the encrypted SSLoad, which is stored in the “.rsrc” section of the DLL. This method keeps the actual payload concealed within the DLL until it’s ready to be executed.

Interestingly, it doesn’t use the common API sequence FindResourceA and LockResource to locate and extract the encrypted resource. Instead, an offset to the encrypted resource is passed to the function that points to the decrypted stub.

Second Loader: SSLoad

The final payload decrypted by PhantomLoader is SSLoad, a rust-based loader known for its evasive and stealthy nature.

It employs various anti-analysis techniques, including anti-debugging and anti-emulation methods. SSLoad also uses multiple layers of string decryption to conceal its Command-and-Control (C2) URLs and IP addresses, making detection and analysis more challenging.

When executed, SSLoad begins by creating a mutex object with a hardcoded name. This object ensures that only one instance of SSLoad can run on the host at any given time. This is a common technique used to avoid resource conflicts or redundant infections on a single host.

It uses a common anti-debugging technique by inspecting the Process Environment Block (PEB), specifically looking for the “BeingDebugged” flag. This flag is set to indicate whether the process is currently being debugged. 

It is interesting to note that it uses an anti-emulation technique that was observed for the first time being used by Raspberry Robin. The technique involves attempting to retrieve the address of a function exported by kernel32 called “MpVmp32Entry”. 

However, when inspecting the exports of kernel32 for this function name, it cannot be found. This is because only modified versions of kernel32.dll used by emulators export that function.

The developers of SSLoad may have either intentionally or accidentally failed to properly decrypt the library name Kernel32.dll. This would result in the DLL base address not being retrieved to check for the target export. As a result, the implemented trick might fail even on an emulated system.

One of the system artifacts to check for is the presence of a directory with a randomly generated name under %APPDATA%/Microsoft. This directory name is generated at runtime using the function SystemFunction036 from the Advapi32.dll library, which is often used for cryptographic functions.

After completing its checks and decrypting the C2 URLs and IP addresses, SSLoad moves forward with fingerprinting the host it’s running on. This process involves collecting various details about the system.

This data is then stored in a JSON object, which will be sent later via POST request to the Command-and-Control (C2) server for further communication.

The fingerprinted data collected by SSLoad includes crucial system information like the OS version, username, hostname, architecture (arch), public IP address, and other system-specific details.

The data will be sent to the server in preparation of C2 communication process. 

If the connection was successful, the C2 server will return back response with a JSON object containing a “key” and an “ID”.

The returned key is a base64 encoded RC4 key that will be used to secure further communication between the host and C2 server. 

In its turn, the ID is a unique identifier generated on the C2 side that will be used by the infected host to authenticate and identify itself to the C2 server. 

In the later HTTP POST requests, no data is sent to the C2 server. Instead, the infected host sends empty HTTP POST requests that contain only the server-side generated “ID”.

Once SSLoad establishes a connection with the C2 server, it enters a beaconing loop, regularly checking in with the server for further instructions or tasks to execute.

It seems that for the current sample the server hasn’t returned any tasks to the infected host. However, in another SSLoad analysis sample, the server did return a response containing an “ID” and a “Job”.

The “ID” returned by the server identifies a task for the infected host.

The encoded structure contains two fields: “command” and “arguments.” Fishbein explained that when the “command” field is set to “exe” and the “arguments” field contains a URL, it indicates that the server is instructing the infected host to download and execute the next-stage malware payload from the given URL.

Indicators of Compromise (IOC)

File Paths and Names 

Incident_Harassment.doc

%TEMP%/app.com

File Hashes (MD5)

EC7E26A81B6002C53854A1769AD427A6

bd3231011448b2d6a335032d11c12cad

E01DDD72BC81781FE86A68D3AD045548

Related Domains, URLs, and IP addresses 

http://85[.]239[.]53[.]219 

YARA Rule

rule crime_phantom_loader_dll

{
    meta:
        description = “Detects PhantomLoader C/C++ DLL”
        author = “Mohamed Talaat”
        date = “2024-17-8”
        type = “crimeware”
        hash1 = “BD3231011448B2D6A335032D11C12CAD”
        hash2 = “CA303668B5420C022EF9C78CE1F2BFB7”
        hash3 = “1D8D71B4A0870C0DFA3468470FB28A28”
        hash4 = “B28A478EB5B99EFCDC7CAF428BFFB89A”
    strings:
        $pdb_str = “C:\vmagent_new\bin\joblist” ascii
        $iobit_str = “IUForceDelete123” ascii wide
        $mov_5F5E100 = { ( BF | 68 | C7 45 ?? ) 00 E1 F5 05 }
        $payload_size = { ( D0 | 6C ) 07 00 00 }
        $call_payload = { FF 55 ?? 68 [4] FF [-] 33 C0 ?? 8B E5 5D C3 }
    condition:
        (uint16(0) == 0x5A4D) and
        all of ($mov_5F5E100, $payload_size, $call_payload) and
        any of ($pdb_str, $iobit_str)
}

The post New PhantomLoader Malware Distributes SSLoad: Technical Analysis appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More