Suspected Threat Actors: Unknown
Researchers recently discovered a new malware family dubbed PRIVATELOG and its installer, STASHLOG. The malware deploys a novel and interesting technique in the samples used to hide data. The PRIVATELOG and STASHLOG rely on CLFS – a log framework that was introduced by Microsoft in Windows Vista and Windows Server 2003 R2 for high performance – to hide a second-stage payload in registry transaction files.
Most strings in PRIVATELOG and STASHLOG are obfuscated with uncommon technique and rely on XOR’ing each byte with a hard-coded byte inline, without loops – making each string encrypted with a unique byte stream.
Some of the de-obfuscated strings were observed to be containing typos as follows:
-> Log index=%d, data border exceed bounday.\n
-> Interal data hash mismatch.\n
-> Log buffer size=%u too small, expect aleast %u bytes.\n
In addition to obfuscated strings, STASHLOG installer’s code itself is protected with various control flow obfuscation techniques that hinder static analysis.
The STASHLOG offers two modes of operations:
-> Without any argument – The installer generates and prints out encryption keys that the threat actor uses to pre-encrypt the payload before it is written to disk.
-> With a single argument – The installer opens and decrypts the contents of the file passed as an argument. The contents of which are subsequently stashed in a specific CLFS log file.
The PRIVATELOG is fashioned as an un-obfuscated 64-bit DLL named “prntvpt.dll,” to leverage a technique called DLL search order hijacking to load the malicious library when it is called by a victim program, in this case, a service called “PrintNotify”.
YARA Rules to hunt for PRIVATELOG and STASHLOG, and their potential variants are listed below:
YARA Rule #1
YARA Rule #2
YARA Rule #3
YARA Rule #4
YARA Rule #5
Since the file format used in CLFS logs is not widely used and remains undocumented, it presents an opportunity for attackers to hide their data as log records in a convenient manner and accessible through API functions.
The technique of hiding data in CLFS log files is similar to malware which may rely, for example, on the Windows Registry or NTFS Extended Attributes to hide their data, which also provide locations to store and retrieve binary data with the Windows API.
CTI observed Socfinaf (https://www.socfin.com) – a holding company of multiple agricultural businesses around Ivory Coast, Zaire, Nigeria, and Liberia – being impacted by the Grief ransomware. It is suspected that the operators have exfiltrated a large amount of business-critical and sensitive data. At the time of CTI’s observation, the threat actor has not published any data in their data leak portal on the dark web, however, they are expected to release the data.
The following screenshots were observed published on the dark web:
Source: Dark Web
Making an appearance around July this year, the Grief ransomware has recently entered the multi-billion-dollar ransomware market alongside another new ransomware player – Prometheus. Grief is comparatively a lesser-known ransomware group, however, had claimed to have stolen data from multiple organizations to date. Their data leak portal located inside the TOR network employs an “anti-crawl” protection that prevents cybersecurity researchers and defenders from automated monitoring of published content by various threat intelligence platforms.
Interestingly, the landing page of their data leak portal has a reference to GDPR (General Data Protection Regulation) Article 33 that essentially requires data controllers to notify any personal data breach to the appropriate authority – a cleaver form scare tactic to extort money out of victims.
This tactic may perhaps turn fruitful for the operators since the victims are faced with a double-edged sword. On one hand, they are duty-bound to report such incidents, on the other hand, the operator will leak the data in an event of non-payment of ransom demand which eventually becomes public knowledge.
Further, the GDPR empowers authorities to issue fines that will be comparatively much higher than possible ransom demands.
The portal also tries to incite the psychological bias of the potential victims by showcasing ‘facts’ such as the possible 10x times higher cost of an unplanned downtime when compared to ransom requests, furnished as infographics for easy and effective consumption.
Researchers disclosed over 60,000 parked domains vulnerable to domain hijacking were left by Domain registrar MarkMonitor. The parked domains were configured to point towards the address of an Amazon S3 bucket that did not exist. As per the researcher, all domains appeared as parked with varying degrees of use and registered via MarkMonitor. While the researchers attempted to contact MarkMonitor’s security contact remained unacknowledged, the domains gradually started furnishing the proper MarkMonitor landing page and stopped pointing to the S3 bucket after an hour. Within this timeframe, researchers were able to claim multiple domains with one research taking over approximately 800 root domains.
DNS configuration is not immune to misconfiguration especially for large corporations it is paramount to maintain proper DNS hygiene. Such a scenario opens doors to the attacker for all kinds of abuse which may lead to a severe impact on the organization and its customers.
However, the (sub)domain takeover vulnerability has remained underestimated and at times overlooked is a widespread flaw largely due to increased adaptation of cloud-based solutions. Organizations need to consider this vulnerability into their threat model due to the following:
-> Surprisingly, a (sub)domain takeover attack remarkably does not require sophisticated technical skills. It is often considered a low-hanging fruit amongst bug hunters since it is often easy to identify and exploit vulnerable subdomains. The same principle applies to threat actors.
-> Detection of (sub)domain takeover being actively exploited is difficult; it may be too late for the organization as damages have already been caused.
-> A minor threat in itself but combined with other attack scenarios in hands of a motivated attacker would lead to significant damage.
In this case where the affected domains included domains from some of the well-known brands including Google and Coinbase – would have been an ideal target for a phishing campaign. Other possible exploitation by a malicious attacker include:
-> Defacement
-> Stealing badly scoped cookies
-> CSRF ((Cross-Site Request Forgery) attack
-> Abuse of over-trusting CORS-Aware (Cross-Origin Resource Sharing) servers
-> Defeating a permissive Content Security Policy (CSP) and launching XSS (Cross-Site Scripting) or Clickjacking attacks
A critical vulnerability in a Cisco product designed to help service providers and enterprises deploy virtualized networks can allow unauthenticated actors to bypass authentication. The security flaw tracked as CVE-2021-34746 achieved a near-maximum CVSS score of 9.8 exists in TACACS+ (Terminal Access Controller Access-Control System) authentication, authorization, and accounting (AAA) feature of Cisco Enterprise NFV Infrastructure Software (NFVIS). The flaw allows a remote, unauthenticated attacker to bypass authentication and login as an administrator on a vulnerable device.
This vulnerability is due to incomplete validation of user-supplied input that is passed to an authentication script. An attacker could exploit this vulnerability by injecting parameters into an authentication request.
While Cisco Product Security Incident Response Team (PSIRT) is not aware of any malicious use of the vulnerability, a proof-of-concept exploit code exists in the wild – urging the organization to update to the latest version as soon as possible. In addition, CISA (Cybersecurity and Infrastructure Security Agency) has also encouraged users and administrators to apply the necessary update.
