Firefox — CraftedSignal Threat Feed

Non-Firefox Process Accessing Firefox Profile Directory

hello@craftedsignal.io — Wed, 03 Jan 2024 15:22:32 +0000

This detection focuses on identifying unauthorized access to Firefox profile directories. The Firefox profile directory stores sensitive user data, including login credentials, browsing history, and cookies. When a non-Firefox process accesses this directory, it could be an indicator of malicious activity, such as a Remote Access Trojan (RAT) or other malware attempting to steal user information. The analytic leverages Windows Security Event logs, specifically event code 4663, to monitor access attempts. This is relevant because successful credential theft can lead to account compromise, data breaches, and further propagation of malware within the network. The threat encompasses a broad range of malware families, including stealers (Azorult, RedLine Stealer, 0bj3ctivity Stealer), RATs (Remcos, Quasar RAT, Warzone RAT), keyloggers (Snake Keylogger, VIP Keylogger), and other malware like DarkGate, NjRAT, AgentTesla, and Lokibot. The activity has been observed in campaigns such as CISA AA23-347A and the 3CX Supply Chain Attack.

Attack Chain

The user executes a malicious file, potentially delivered via phishing or drive-by download (not covered in source).
The malicious file executes and establishes persistence on the system.
The malware attempts to access the Firefox profile directory, located at *\AppData\Roaming\Mozilla\Firefox\Profiles*.
Windows Security Event 4663 is generated, logging the access attempt to the Firefox profile directory.
The malware reads sensitive data, such as login credentials, cookies, and browsing history, from the profile directory.
The stolen data is exfiltrated to a command-and-control (C2) server.
The attacker uses the stolen credentials to gain unauthorized access to user accounts and sensitive systems.

Impact

Successful exploitation and credential theft can lead to a wide range of negative outcomes, including unauthorized access to sensitive data, financial fraud, and further compromise of systems within the organization. The impact can range from individual user account compromise to large-scale data breaches affecting thousands of users. Industries heavily reliant on web-based applications and sensitive user data, such as finance, healthcare, and e-commerce, are particularly vulnerable. The consequences include financial losses, reputational damage, and legal liabilities.

Recommendation

Enable “Audit Object Access” in Group Policy and configure it to log both success and failure events for object access to activate the underlying log source required for this detection.
Deploy the provided Sigma rule to your SIEM to detect non-Firefox processes accessing Firefox profile directories.
Investigate any alerts generated by the Sigma rule, paying close attention to the ProcessName and ObjectName to identify potentially malicious processes and the specific profile data being accessed.
Review and update your organization’s security policies to restrict unauthorized access to sensitive user data.

Unusual Process Loading Mozilla NSS/Mozglue Module

hello@craftedsignal.io — Wed, 03 Jan 2024 14:30:00 +0000

This brief focuses on detecting anomalous loading of Mozilla NSS (Network Security Services) and Mozglue libraries (specifically mozglue.dll and nss3.dll) by processes other than known Mozilla applications like Firefox and Thunderbird. The technique leverages Windows Sysmon Event ID 7 (ImageLoaded) to identify such instances. This activity is flagged as suspicious because legitimate software rarely loads these libraries outside of the intended Mozilla ecosystem. Attackers may attempt to load these libraries into other processes to perform malicious actions such as code injection, data exfiltration, or credential theft, while masquerading as legitimate software. This detection is crucial for identifying potentially compromised systems and preventing further damage.

Attack Chain

Initial Access: An attacker gains initial access to the system, possibly through phishing, exploiting a vulnerability, or using stolen credentials.
Persistence: The attacker establishes persistence on the system, ensuring continued access even after a reboot. This may involve creating scheduled tasks or modifying registry keys.
Privilege Escalation: The attacker elevates privileges to gain higher-level access to the system. This can be achieved through exploiting kernel vulnerabilities or misconfigured services.
Malware Installation: The attacker deploys malware or malicious tools onto the compromised system. This may involve downloading executables or scripts from a remote server.
Code Injection: The attacker injects malicious code into a legitimate process. This is often done to evade detection and execute malicious commands in a trusted context. In this scenario, the injected code might leverage Mozilla NSS/Mozglue libraries.
Credential Theft: The injected code attempts to steal credentials stored on the system. This may involve accessing LSASS memory or extracting credentials from web browsers.
Data Exfiltration: The attacker exfiltrates sensitive data from the compromised system. This may involve compressing data and transferring it to a remote server using protocols like HTTP or FTP.
Lateral Movement/Impact: Using stolen credentials or the compromised system as a pivot, the attacker moves laterally within the network to compromise additional systems, or achieves their ultimate objective, such as ransomware deployment or intellectual property theft.

Impact

Successful exploitation and anomalous loading of Mozilla libraries can lead to significant damage, including data breaches, financial loss, and reputational damage. Stolen credentials can be used to access sensitive systems and data, while injected code can disrupt critical business processes. The scope can range from individual workstations to entire networks, depending on the attacker’s objectives and level of access. The detection helps prevent credential theft, data exfiltration, and lateral movement.

Recommendation

Enable Sysmon Event ID 7 (ImageLoaded) logging on all Windows endpoints to ensure visibility into loaded modules (reference: data_source).
Deploy the Sigma rule Unusual Mozilla NSS/Mozglue Module Load by Non-Mozilla Process to your SIEM and tune the process exceptions for your environment (reference: rules).
Investigate any instances where Mozilla NSS/Mozglue libraries are loaded by processes not explicitly allowed in the exception list to determine if malicious activity is occurring (reference: search).
Correlate detections of unusual Mozilla library loading with other suspicious activity, such as network connections to known malicious domains or the execution of unusual processes, to identify potential compromises (reference: tags).
Review and update the list of legitimate applications that may load Mozilla NSS/Mozglue libraries in your environment to reduce false positives (reference: known_false_positives).

Kerberos Traffic from Unusual Process

hello@craftedsignal.io — Wed, 03 Jan 2024 14:00:00 +0000

This detection identifies unusual processes initiating network connections to the standard Kerberos port (88) on Windows systems. Typically, the lsass.exe process handles Kerberos traffic on domain-joined hosts. The rule aims to detect processes other than lsass.exe communicating with the Kerberos port, which could indicate malicious activity such as Kerberoasting (T1558.003) or Pass-the-Ticket (T1550.003). The detection is designed to work with data from Elastic Defend and SentinelOne Cloud Funnel. This can help security teams identify potential credential access attempts and lateral movement within the network.

Attack Chain

An attacker compromises a user account or system within the domain.
The attacker executes a malicious binary or script (e.g., PowerShell) on the compromised system.
The malicious process attempts to request Kerberos service tickets (TGS) for various services within the domain. This is done by connecting to the Kerberos port (88) on a domain controller.
The attacker uses tools like Rubeus or Kerberoast.ps1 to enumerate and request TGS tickets.
The unusual process (not lsass.exe) sends Kerberos traffic to the domain controller.
The attacker extracts the Kerberos tickets from memory or network traffic.
The attacker cracks the offline TGS tickets to obtain service account passwords (Kerberoasting).
The attacker uses the compromised service account credentials to move laterally within the network or access sensitive data.

Impact

A successful Kerberoasting or Pass-the-Ticket attack can lead to unauthorized access to sensitive resources and lateral movement within the network. Attackers can compromise service accounts with elevated privileges, potentially leading to domain-wide compromise. Detection of this behavior can prevent attackers from gaining access to critical assets. While the exact number of victims and sectors targeted are unknown, this technique is widely used by various threat actors in targeted attacks.

Recommendation

Deploy the “Kerberos Traffic from Unusual Process” Sigma rule to your SIEM and tune for your environment. Enable network connection logging to capture the necessary traffic.
Investigate any alerts triggered by the Sigma rule, focusing on the process execution chain and potential malicious binaries.
Review event ID 4769 for suspicious ticket requests as mentioned in the rule’s documentation.
Examine host services for suspicious entries as outlined in the original Elastic detection rule using Osquery.
Monitor for processes connecting to port 88, filtering out legitimate Kerberos clients like lsass.exe, using the “Detect Kerberos Traffic from Non-Standard Process” Sigma rule.
Investigate processes identified by the rule and compare them to the list of legitimate processes to identify unauthorized connections to the Kerberos port.

RMM Domain DNS Queries from Non-Browser Processes

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This detection identifies potentially malicious use of Remote Monitoring and Management (RMM) tools by detecting DNS queries to known RMM domains originating from processes that are not web browsers. Attackers frequently abuse legitimate RMM software for command and control, persistence, and lateral movement within compromised networks. This rule focuses on surfacing RMM clients, scripts, or other non-browser activity contacting these services, thereby increasing the likelihood of detecting unauthorized remote access or malicious activity. The rule aims to reduce false positives by excluding common browser processes and focusing on unusual network activity. The identified domains are associated with various RMM tools like TeamViewer, AnyDesk, and ScreenConnect. This detection is relevant for organizations concerned about insider threats, supply chain attacks, or general compromise leading to unauthorized remote access.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker installs an unauthorized RMM tool (e.g., using a script or installer).
The RMM tool initiates a DNS query to resolve its command and control domain (e.g., teamviewer.com).
The system, now running the RMM agent, establishes a connection to the attacker-controlled RMM server.
The attacker uses the RMM tool to execute commands on the compromised system.
The attacker uses the RMM tool for lateral movement within the network.
The attacker uses the RMM tool to maintain persistence on the compromised system.

Impact

Compromise via unauthorized RMM tools can provide attackers with persistent remote access, enabling them to perform a range of malicious activities, including data theft, ransomware deployment, and further lateral movement within the network. Successful exploitation can lead to significant financial loss, reputational damage, and disruption of business operations. The number of affected systems can vary depending on the scope of the initial compromise and the attacker’s ability to move laterally.

Recommendation

Deploy the Sigma rule RMM Domain DNS Queries from Non-Browser Processes to your SIEM and tune it to your environment, excluding legitimate non-browser processes that use RMM tools.
Investigate any alerts generated by the rule, focusing on identifying the process making the DNS query and its parent process, as outlined in the rule’s description.
Monitor DNS query logs for queries to the RMM domains listed in the IOC table, and block them at the DNS resolver if unauthorized RMM use is confirmed.
Enable Sysmon Event ID 22 (DNS Query) logging to provide the necessary data for this detection, as recommended in the “Setup” section of the content.

DNS-over-HTTPS Enabled via Registry Modification

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The use of DNS-over-HTTPS (DoH) can obscure network activity, potentially allowing malicious actors to bypass traditional DNS monitoring and conceal data exfiltration. When DoH is enabled, visibility into DNS query types, responses, and originating IPs is lost, hindering the detection of malicious activity. This behavior is detected by monitoring registry modifications associated with enabling DoH in popular browsers such as Microsoft Edge, Google Chrome, and Mozilla Firefox. The registry keys targeted are associated with settings that force the browsers to use secure DNS resolution, potentially circumventing organizational security policies.

Attack Chain

Initial Access: An attacker gains initial access to a Windows system through various means, such as phishing or exploiting a software vulnerability.
Privilege Escalation (if necessary): The attacker may need to escalate privileges to modify registry settings.
Defense Evasion: The attacker modifies the Windows registry to enable DNS-over-HTTPS (DoH) in web browsers like Edge, Chrome, or Firefox. This is achieved by modifying specific registry keys such as HKLM\SOFTWARE\Policies\Microsoft\Edge\BuiltInDnsClientEnabled, HKLM\SOFTWARE\Google\Chrome\DnsOverHttpsMode, or HKLM\SOFTWARE\Policies\Mozilla\Firefox\DNSOverHTTPS.
Obfuscation: By enabling DoH, the attacker encrypts DNS queries, making it difficult for network monitoring tools to inspect DNS traffic.
Command and Control: The attacker establishes command and control (C2) communication with a remote server over encrypted DNS traffic, evading traditional network-based detection methods.
Data Exfiltration: The attacker uses the encrypted DNS channel to exfiltrate sensitive data, bypassing network security controls that rely on DNS inspection.
Persistence (Optional): The attacker might establish persistence by ensuring the DoH settings remain enabled across system reboots.

Impact

Successful exploitation leads to a loss of visibility into DNS traffic, hindering incident response and threat hunting efforts. Attackers can effectively hide command-and-control communications and data exfiltration activities. Although this activity by itself isn’t inherently malicious, it removes a layer of defense, increasing the risk that malicious activities will go undetected.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM to detect the enabling of DNS-over-HTTPS via registry modifications.
Enable Sysmon registry event logging to capture the necessary events for the provided Sigma rules to function effectively.
Review and update security policies to ensure DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse, and create exceptions in the detection rule for systems where this is a known requirement.
Investigate any alerts generated by the Sigma rules, focusing on identifying the user account, process, and associated network activity (reference the investigation guide in the source URL).

Windows Scheduled Task Creation for Persistence

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Adversaries frequently leverage scheduled tasks in Windows to maintain persistence, elevate privileges, or facilitate lateral movement within a compromised network. This technique involves creating or modifying scheduled tasks to execute malicious code at specific times or intervals. The detection rule focuses on identifying the creation of new scheduled tasks logged in Windows event logs, filtering out tasks created by system accounts and those associated with legitimate software to minimize false positives. This detection is crucial because successful exploitation allows attackers to execute arbitrary commands or programs on a recurring basis, maintaining a foothold even after system reboots or user logoffs. Defenders need to monitor for anomalous task creation events to identify potential malicious activity. The rule references Microsoft Event ID 4698 as a key data source for detecting scheduled task creation.

Attack Chain

Initial Access: An attacker gains initial access to the system through phishing, exploiting a vulnerability, or using compromised credentials.
Privilege Escalation (if needed): The attacker escalates privileges using exploits or by abusing misconfigurations to gain the necessary permissions to create scheduled tasks.
Task Creation: The attacker creates a new scheduled task using tools like schtasks.exe or PowerShell.
Configuration: The attacker configures the task to execute a malicious script or program at a specific time or event trigger.
Persistence: The scheduled task is configured to run at regular intervals or upon system startup, ensuring persistent access to the compromised system.
Execution: When the scheduled task triggers, the malicious payload executes, performing actions such as installing malware, stealing data, or establishing a command and control connection.
Lateral Movement (optional): The attacker uses the compromised system and scheduled task to move laterally to other systems on the network, repeating the task creation process.

Impact

Successful exploitation via scheduled task creation can lead to persistent access within the compromised environment. The attacker can maintain a foothold even after system restarts, enabling them to perform data exfiltration, deploy ransomware, or cause other disruptive activities. While the risk score is relatively low, the potential for persistence makes this a critical area to monitor, especially in environments where lateral movement is a significant concern. The number of affected systems depends on the scope of the initial compromise and the attacker’s ability to move laterally.

Recommendation

Enable “Audit Other Object Access Events” to generate the necessary Windows Security Event Logs for detecting scheduled task creation (reference: setup instructions in the original rule).
Deploy the provided Sigma rules to your SIEM to detect suspicious scheduled task creation events, and tune the rules by adding exclusions for known benign tasks in your environment.
Review the investigation steps outlined in the rule’s notes to triage alerts related to scheduled task creation, focusing on unfamiliar task names, unusual user accounts, and suspicious scheduled actions.
Use the references URL to understand the specific details of Windows Event ID 4698, which is generated when a scheduled task is created.

Masquerading Business Application Installers

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Attackers often attempt to trick users into downloading and executing malicious executables by disguising them as legitimate business applications. This tactic is used to bypass security measures and gain initial access to a system. These malicious executables, often distributed via malicious ads, forum posts, and tutorials, mimic the names of commonly used applications such as Slack, WebEx, Teams, Discord, and Zoom. The executables are typically unsigned or signed with invalid certificates to further evade detection. This allows the attacker to execute arbitrary code on the victim’s machine, potentially leading to further compromise. This campaign aims to target end-users who are less security-aware, and this makes social engineering attacks like this very effective.

Attack Chain

The user visits a compromised website or clicks on a malicious advertisement.
The user is prompted to download an installer file masquerading as a legitimate business application (e.g., Slack, Zoom, Teams) from a download directory.
The downloaded executable is placed in the user’s Downloads folder (e.g., C:\Users*\Downloads*).
The user executes the downloaded file.
The executable, lacking a valid code signature, begins execution.
The malicious installer may drop and execute additional malware components.
The malware establishes persistence, potentially using techniques such as registry key modification.
The malware performs malicious activities, such as data exfiltration or lateral movement.

Impact

Successful execution of a masqueraded business application installer can lead to a complete system compromise. The attacker gains initial access and can deploy various malware payloads, including ransomware, keyloggers, and data stealers. This can result in data breaches, financial loss, and reputational damage. Although the specific number of victims and sectors targeted are not detailed, the widespread use of the applications being spoofed (Slack, Zoom, etc.) suggests a broad potential impact.

Recommendation

Implement the Sigma rule Potential Masquerading as Business App Installer to detect unsigned executables resembling legitimate business applications in download directories.
Enable process creation logging to capture the execution of unsigned executables.
Educate users on the risks of downloading and executing files from untrusted sources.
Implement application whitelisting to restrict the execution of unauthorized applications.
Regularly update endpoint detection and response (EDR) tools to detect and prevent the execution of known malware.
Monitor process execution events for processes originating from the Downloads folder that lack valid code signatures.

Detecting Suspicious Scheduled Task Creation in Windows

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Adversaries frequently abuse Windows scheduled tasks to establish persistence, move laterally within a network, and escalate privileges. This technique involves creating or modifying scheduled tasks to execute malicious code at specific times or in response to certain events. This detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. The rule relies on Windows Security Event Logs, offering a valuable method for identifying unauthorized task creation indicative of malicious activity. The detection logic specifically excludes common tasks associated with software updates from vendors like Hewlett-Packard, Microsoft, Google, and Mozilla, as well as tasks run by system accounts.

Attack Chain

An attacker gains initial access to a system, potentially through phishing or exploiting a vulnerability.
The attacker uses their initial access to execute commands, potentially leveraging PowerShell or cmd.exe.
The attacker uses the schtasks command-line utility or the COM interface to create a new scheduled task.
The scheduled task is configured to execute a malicious payload, such as a reverse shell or a data exfiltration script.
The task is set to trigger based on a specific schedule, such as at system startup, at a specific time, or upon a specific event.
When the trigger occurs, the scheduled task executes the malicious payload.
The malicious payload establishes persistence, allowing the attacker to maintain access to the compromised system.
The attacker can then use the persistent access to move laterally to other systems or to exfiltrate sensitive data.

Impact

Successful exploitation allows adversaries to maintain persistent access to compromised systems, potentially leading to data theft, system disruption, or further lateral movement within the network. By creating malicious scheduled tasks, attackers can ensure their code is executed even after a system reboot or user logoff. This can result in long-term compromise and significant damage to affected organizations. While the number of victims and specific sectors targeted are not detailed, the potential impact is broad due to the widespread use of Windows systems in enterprise environments.

Recommendation

Enable Windows Security Event Logging and ensure that event ID 4698 (A scheduled task was created) is collected.
Deploy the Sigma rule “Suspicious Scheduled Task Creation via Winlog” to your SIEM to detect potentially malicious scheduled task creation events.
Regularly review and update the exclusion list in the Sigma rule to account for new benign scheduled tasks in your environment.
Investigate any alerts generated by the Sigma rule by examining the task’s name, path, actions, and triggers to determine if they are suspicious.
Monitor for related suspicious activity, such as unusual process executions or network connections originating from the compromised system.