Account-Creation - CraftedSignal Threat Feed

FileBrowser Authentication Bypass via Forged Proxy Authentication Header

hello@craftedsignal.io — Fri, 10 Jul 2026 19:37:06 +0000

A critical authentication bypass vulnerability affects FileBrowser instances configured to use proxy authentication (auth.method=proxy) where the application server is directly exposed to untrusted networks. This allows any unauthenticated attacker to impersonate any existing user, including the administrator, by simply sending a forged X-Remote-User HTTP header during a POST request to the /api/login endpoint. Additionally, specifying a non-existent username in the forged header causes FileBrowser to automatically create a new user account with default permissions, providing an account creation primitive without authorization. This vulnerability stems from FileBrowser unconditionally trusting the X-Remote-User header without any origin validation or password verification, a behavior present across all versions that support this authentication method. This is a common misconfiguration for organizations using reverse proxies for SSO/LDAP/OAuth. Successful exploitation grants full administrative control over the FileBrowser instance and access to all hosted files.

Attack Chain

An unauthenticated attacker identifies a FileBrowser instance configured with auth.method=proxy that is directly reachable (i.e., not exclusively behind a trusted reverse proxy).
The attacker crafts an HTTP POST request to the /api/login endpoint, including a forged HTTP header, typically X-Remote-User, set to a target username such as admin.
FileBrowser's ProxyAuth.Auth() function receives the request and extracts the username from the X-Remote-User header, implicitly trusting its value without any origin validation (e.g., checking trusted IP addresses) or cryptographic verification.
If the specified username exists, FileBrowser retrieves the corresponding user object from its internal user store. If the username does not exist, the createUser() function is automatically invoked, creating a new user account with default permissions and a locked, random password.
The loginHandler proceeds to mint a valid JSON Web Token (JWT) for the impersonated or newly created user. This JWT contains the full permissions of the target user, including administrator privileges if admin was specified.
The attacker receives this valid JWT and uses it in subsequent HTTP requests by including it in the X-Auth header to interact with privileged endpoints (e.g., /api/settings, /api/users) or access specific user resources (e.g., /api/resources/).
The attacker achieves full administrative control over the FileBrowser instance, allowing modification of server settings, enumeration of all user accounts, and unauthorized access to all files and data within the application's scope.

Impact

Successful exploitation of this vulnerability leads to complete compromise of the FileBrowser instance. Attackers gain full administrative control, allowing them to modify server configurations, create, delete, or modify files, and access sensitive data stored within the FileBrowser environment. This also enables the creation of arbitrary user accounts without authorization, potentially leading to further persistence or resource exhaustion. Organizations deploying FileBrowser behind reverse proxies, especially those exposing the application's port directly to an untrusted network (e.g., due to Docker container defaults or misconfigured cloud security groups), are at high risk of data breach and system compromise.

Recommendation

Restrict direct access: Configure network firewalls or security groups to ensure the FileBrowser application is only accessible by trusted reverse proxies, preventing direct access from untrusted networks.
Review logging: Deploy the provided Sigma rule to detect POST requests to /api/login containing the X-Remote-User header. Ensure web server logs capture the X-Remote-User HTTP header for effective detection.
Update configuration: If direct exposure is unavoidable, consider switching auth.method from proxy to json and implementing alternative, more secure authentication mechanisms at the application layer or within a properly secured reverse proxy setup.
Implement trusted proxy validation: If using auth.method=proxy is essential, implement stringent trusted proxy validation at the network layer or enhance FileBrowser with origin validation checks (e.g., by contributing a patch to verify r.RemoteAddr against a list of trusted IPs).

Ivanti VTM Administrator Account Creation via CVE-2024-7593

hello@craftedsignal.io — Wed, 03 Jul 2024 10:00:00 +0000

CVE-2024-7593 is an authentication bypass vulnerability affecting Ivanti Virtual Traffic Manager (vTM), a widely used application delivery controller. This vulnerability allows unauthenticated remote attackers to bypass the admin panel's authentication mechanisms and create new administrator accounts. Exploitation of this flaw enables attackers to gain complete control over the Ivanti vTM instance, potentially disrupting services, intercepting traffic, and compromising sensitive data. Public proof-of-concept exploit code exists, increasing the likelihood of widespread exploitation. Successful exploitation can lead to a complete compromise of the vTM instance and the services it manages. The targets are organizations using vulnerable versions of Ivanti vTM, which are primarily web-facing applications requiring load balancing and traffic management.

Attack Chain

An unauthenticated attacker sends a crafted HTTP request to the Ivanti vTM admin panel, exploiting CVE-2024-7593 to bypass authentication.
The attacker leverages the authentication bypass to gain unauthorized access to the vTM admin interface.
The attacker uses the exposed administrative functionality to create a new user account with "admin" privileges via the 'adduser' operation.
The new administrator account lacks expected authentication details in the vTM audit logs, specifically showing IP="!!ABSENT!!".
The attacker logs in to the Ivanti vTM admin panel using the newly created administrator account.
Once authenticated, the attacker configures the vTM instance to redirect traffic to attacker-controlled servers.
The attacker intercepts sensitive data, including credentials and session tokens, from the redirected traffic.
The attacker uses the compromised data to gain access to backend systems and escalate their access within the network, potentially leading to data exfiltration or ransomware deployment.

Impact

Successful exploitation of CVE-2024-7593 allows attackers to gain full administrative control over affected Ivanti vTM instances. This can result in service disruption, data interception, and complete compromise of the applications managed by the vTM. Organizations in various sectors utilizing Ivanti vTM for critical application delivery are at risk. The creation of rogue administrator accounts can lead to unauthorized configuration changes, potentially impacting hundreds or thousands of users accessing web applications. A successful attack can lead to significant financial losses, reputational damage, and regulatory penalties.

Recommendation

Deploy the Sigma rule Ivanti VTM New Account Creation to detect unauthorized administrator account creation attempts based on the absence of IP addresses in the audit logs.
Ensure Ivanti vTM audit logs are properly ingested and monitored, focusing on events with OPERATION="adduser" and MODGROUP="admin" as described in the detection rule.
Review existing Ivanti vTM accounts and configurations for any unauthorized changes or additions that may indicate prior compromise.
Apply the security patches provided by Ivanti to address CVE-2024-7593 on all affected vTM instances. Refer to the Ivanti security advisory for patch availability.
Implement network segmentation and access controls to limit the potential impact of a compromised vTM instance, mitigating lateral movement as described in the attack chain.
Investigate any alerts generated by the Ivanti VTM New Account Creation Sigma rule, correlating with other security events to identify potentially compromised systems.

Windows User Account Creation via net.exe

hello@craftedsignal.io — Tue, 09 Jan 2024 15:00:00 +0000

Attackers may create new accounts (both local and domain) to maintain access to victim systems. This is often done after initial compromise to ensure continued access even if initial entry points are closed. This rule identifies the usage of net.exe (and net1.exe) to create new accounts on Windows systems. The rule specifically looks for the user and /add parameters in the command line arguments. The timeframe analyzed is the last 9 minutes based on the from field in the original rule. This activity, while potentially legitimate, warrants investigation due to its potential for malicious use by threat actors aiming for persistence. The detection logic excludes scenarios where the parent process is also net.exe to reduce noise from legitimate administrative tasks.

Attack Chain

An attacker gains initial access to a Windows system, potentially through exploitation of a vulnerability or stolen credentials.
The attacker executes net.exe with the user and /add arguments to create a new local or domain user account.
The new user account is configured with specific privileges, potentially adding it to local administrator groups.
The attacker uses the newly created account to log into the system, bypassing existing security controls.
The attacker uses the new account to install malware or other malicious tools on the system.
The attacker establishes persistence by adding the newly created account to startup programs or scheduled tasks.
The attacker uses the persistent access to move laterally within the network, compromising additional systems.
The attacker achieves their ultimate objective, such as data exfiltration or ransomware deployment, leveraging the established persistence.

Impact

Successful creation of malicious user accounts can lead to persistent access within a compromised environment. While this event may be legitimate, unauthorized account creation can allow attackers to maintain access to systems even after initial vulnerabilities are patched or detected. Depending on the privileges granted to the created account, the impact can range from limited access to complete control over the compromised system and potentially the entire domain. This can facilitate data theft, disruption of services, or the deployment of ransomware.

Recommendation

Deploy the Sigma rule Detect Windows User Account Creation via net.exe to your SIEM to detect suspicious account creation attempts.
Enable Sysmon process creation logging to ensure the necessary data is available for the Sigma rule to function correctly.
Investigate all instances flagged by the Sigma rule, paying close attention to the parent processes and the context of the account creation.
Correlate detected events with other suspicious activities on the host or network to identify potentially compromised systems.
Review existing account creation policies and procedures to ensure they are adequate and enforced.
Implement multi-factor authentication for all user accounts to mitigate the risk of unauthorized access.
Monitor security logs from Windows Security Event Logs for event IDs related to account creation (4720, 4722, 4723, 4724, 4725).

Cisco ASA - New Local User Account Creation

hello@craftedsignal.io — Thu, 04 Jan 2024 12:00:00 +0000

This analytic detects the creation of new user accounts on Cisco ASA devices via CLI or ASDM. Adversaries may create unauthorized user accounts to establish persistence, maintain backdoor access, or elevate privileges on network infrastructure devices. These rogue accounts can provide attackers with continued access even after initial compromise vectors are remediated. The detection monitors for ASA message ID 502101, which is generated whenever a new user account is created on the device, capturing details including the username, privilege level, and the administrator who created the account. The source material was published by Splunk on 2026-04-17, highlighting the continued relevance of this threat.

Attack Chain

Initial access to the Cisco ASA device via compromised credentials or exploitation of a vulnerability.
Attacker authenticates to the ASA device using the gained access.
Attacker executes commands to create a new local user account using the CLI or ASDM interface.
The ASA device generates syslog message ID 502101, indicating the new account creation, which includes the username, privilege level, and creating administrator.
The attacker assigns a high privilege level (e.g., level 15) to the new account.
Attacker uses the newly created account to maintain persistent access to the ASA device.
Attacker leverages the persistent access to perform reconnaissance, modify configurations, or disrupt network operations.
The attacker establishes a backdoor for future access, bypassing normal authentication mechanisms.

Impact

Successful exploitation can lead to unauthorized access to the network infrastructure, allowing attackers to modify configurations, intercept traffic, or disrupt services. This can result in data breaches, denial of service, and significant financial and reputational damage. While the specific number of victims or targeted sectors isn't available, the impact is significant for any organization relying on Cisco ASA devices for network security.

Recommendation

Ensure Cisco ASA devices are configured to generate and forward syslog message ID 502101 to a SIEM for monitoring to enable the provided detections.
Implement the provided Sigma rule Cisco ASA - New Local User Account Created to detect suspicious account creation activities.
Investigate any alerts generated by the Sigma rule, paying close attention to accounts with elevated privileges (level 15) and those created outside of normal business hours.
Review existing user accounts on Cisco ASA devices regularly, looking for any unauthorized or suspicious accounts.