DarkGate malware account creation

Threat snapshot

DarkGate is a malware-as-a-service loader that has been in active development and distribution since at least 2018. It combines the capabilities of a loader, a remote access trojan, and an information stealer into a single payload, and is sold to multiple threat actors simultaneously through underground forums. This means that DarkGate infections can originate from different groups with different objectives: some operators use it for credential theft, others as a precursor to ransomware, and others for sustained espionage access. What they have in common is the post-infection behaviour the malware executes to establish persistence and consolidate control.

One of DarkGate's documented post-exploitation behaviours is the creation of a local Windows user account using net.exe, the native Windows network management utility. This account is created silently, added to the local Administrators group, and used to maintain persistent interactive access to the infected host independently of the originally compromised user session. Log360 detects this specific behaviour through the DarkGate - User Created Via Net.EXE rule, which monitors for net.exe invocations carrying user creation arguments in the context associated with this malware family. The rule targets the account creation step specifically because it is a high-confidence, attributable action: creating a local administrator account via net.exe from a non-administrative context is not a routine occurrence on a managed endpoint.

At a glance

How this attack works

DarkGate is delivered through multiple vectors, the most common being phishing emails with malicious attachments, malvertising campaigns that redirect users to drive-by download pages, and abuse of legitimate file-sharing and collaboration platforms to distribute payloads disguised as documents or software installers. Once a user opens the malicious file or installer, DarkGate loads into memory, establishes a C2 connection, and begins executing its post-exploitation routine.

The account creation step is part of DarkGate's persistence and access consolidation routine. The malware executes net.exe with user creation arguments, typically following a pattern such as:

net user <username> <password> /add

net localgroup administrators <username> /add

The username and password chosen by DarkGate operators vary across campaigns but commonly use names that mimic legitimate system accounts, IT support account naming conventions, or generic names that blend into the local account list. The account is added to the local Administrators group in a second net.exe call, granting it full local administrative rights.

Once this account exists, the attacker has a persistent, high-privilege local account that they can use to authenticate to the host via RDP, WMI, SMB admin shares, or any other remote access method that accepts local credentials. This access persists independently of the DarkGate malware itself: even if the malware binary is detected and removed, the rogue account remains on the system unless specifically identified and deleted. It also persists through user password changes and account lockouts on the original compromised account, because it is a completely separate local identity.

Why net.exe is used for this step

DarkGate uses net.exe rather than PowerShell or a custom binary for user creation because net.exe is a native Windows binary that is present on every Windows installation, requires no additional tooling, and historically generated less EDR and AV scrutiny than PowerShell-based account creation. The specific combination of net user /add followed by net localgroup administrators /add in rapid succession under a non-administrative parent process, or under a process associated with a malicious payload, is the behavioural fingerprint this rule targets.

Attack chain

The table below maps each stage of a DarkGate infection with account creation persistence to the corresponding MITRE ATT&CK technique.

Real-world scenario

A marketing agency with 60 employees uses Microsoft 365 for email and collaboration. An employee in the creative team receives an email appearing to originate from a freelance contractor, containing a link to what is presented as a shared design brief on an external file platform. The link leads to a page that prompts the employee to download a viewer application to open the file. The viewer is a DarkGate dropper disguised as an AutoIt-compiled installer.

The employee installs the application. DarkGate executes in memory, establishes a C2 connection, and within 90 seconds runs two net.exe commands from within the AutoIt process context: net user helpdesk01 P@ssw0rd123 /add, followed by net localgroup administrators helpdesk01 /add. The account name helpdesk01 is chosen to blend in with what an IT support account might look like on a managed endpoint.

Log360 fires the DarkGate - User Created Via Net.EXE alert within two minutes of the account creation. The SOC analyst reviews the alert, notes that the parent process of net.exe is an AutoIt-compiled binary in the user's Downloads folder, and immediately escalates. The host is isolated within seven minutes of the initial infection. The helpdesk01 account is found and removed. A subsequent investigation reveals that DarkGate had also written a scheduled task to relaunch itself at user login, which is removed during eradication. No data exfiltration is confirmed, but credential harvesting cannot be ruled out for the 90-second window before isolation.

Why this happens

DarkGate's delivery through legitimate-looking file sharing platforms exploits user trust in collaboration tools that are part of daily workflows. Employees who are accustomed to receiving links to files on sharing platforms have no reliable way to distinguish a malicious page from a legitimate one without technical controls in place. The 90-second window between execution and account creation demonstrates how quickly DarkGate moves through its post-exploitation routine. Detection of the account creation step is not an early warning of infection. It is a confirmation that the malware has already completed

Business impact: What can go wrong

A DarkGate infection that goes undetected beyond the account creation phase carries significant and escalating consequences:

• Persistent backdoor account: the rogue local administrator account created by DarkGate provides the attacker with a persistent, high-privilege access path that survives malware removal, user password changes, and endpoint reboots. If not specifically identified and deleted during remediation, it remains active indefinitely.
• Credential harvesting: DarkGate's built-in information stealer component extracts credentials from browsers, email clients, and Windows credential stores. These credentials may include VPN access, cloud service logins, banking portals, and internal application passwords, all usable by the attacker after the initial infection is remediated.
• Secondary payload delivery: DarkGate functions as a loader for additional malware. Operators who have established access via DarkGate may deploy ransomware, additional RATs, or banking trojans as secondary payloads. The DarkGate infection is often not the end goal but the initial foothold for a larger campaign.
• Lateral movement: the rogue local administrator account can be used for lateral movement to other hosts on the network, particularly in environments where the same local admin password is shared or where the infected host has network access to shared resources. DarkGate operators are known to use their access for internal network reconnaissance before deploying secondary payloads.
• Data exfiltration: DarkGate's file transfer capability allows operators to copy documents, design files, financial records, and any other accessible data from the infected host and from network shares accessible from it.
• Reputational damage: marketing agencies and professional services firms that handle client intellectual property and confidential project materials face significant reputational consequences if a DarkGate infection results in client data theft or in the infected host being used to send further phishing emails to clients.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the DarkGate - User Created Via Net.EXE rule can fire reliably, ensure the following are in place:

• Windows Process Creation auditing with command-line logging is enabled on all monitored endpoints, generating Event ID 4688 with the full ProcessCommandLine field populated. The rule depends on the command-line arguments of the net.exe invocation being visible in the log. Without command-line logging, net.exe process creation events will appear but the user /add arguments confirming account creation intent will not be present.
• Windows Account Management auditing is enabled on all endpoints, generating Event ID 4720 (User Account Created) and Event ID 4732 (Member Added to Security-Enabled Local Group). These events provide the secondary confirmation that the account was actually created, independent of the process creation event.
• Sysmon is deployed on all monitored endpoints with a configuration capturing Event ID 1 (Process Create). Sysmon provides the parent process chain needed to identify the malware component responsible for spawning net.exe, which is the primary differentiator between malware-initiated account creation and legitimate administrative account creation.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from all monitored endpoints to Log360. DarkGate targets end-user workstations as its primary infection vector. Coverage must include all workstations, not only servers.

Note: The DarkGate - User Created Via Net.EXE rule is most effective when command-line logging is enabled, because the /add argument in the net.exe command line is the primary detection anchor. If command-line logging is disabled on endpoints, consider enabling the complementary account management auditing rules (Event ID 4720 and 4732) with alerting for accounts created outside documented provisioning windows, as these will fire regardless of command-line logging status.

Detecting DarkGate malware account creation using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: DarkGate - User Created Via Net.EXE. Configure an alert profile for the same. Set the severity to Critical. Account creation via net.exe from a non-administrative parent process on a user workstation is not a routine occurrence in a managed environment, and any alert from this rule on a user endpoint warrants immediate investigation.

Step 2: Read the alert

When the rule fires, the alert will display the hostname, the user account context under which net.exe ran, the full command line including the new account name and the /add flag, the parent process name and path, and the timestamp. Review the parent process path first. A parent in a system directory such as System32 or Program Files is lower risk than a parent in AppData, Temp, Downloads, or a user profile path. Then review the new account name: names that mimic system accounts, IT support accounts, or service accounts are a strong DarkGate indicator. Finally check whether a second net.exe call adding the new account to the local Administrators group appears in the same time window.

Investigating an alert

When the DarkGate - User Created Via Net.EXE rule fires, an L2 analyst should work through the following steps:

• Identify the parent process chain. Open the Incident Workbench and trace the full process tree back from net.exe to the original execution vector. Determine what spawned the process that spawned net.exe. If the chain leads back to an email attachment, a downloaded installer, or a browser-spawned process, DarkGate infection is confirmed. Identify the binary responsible and its location on disk.
• Check whether the new account was added to the Administrators group. Query Log360 for Event ID 4732 on the same host within 60 seconds of the account creation alert. A group addition event showing the new account being added to the Administrators group in the same time window confirms the full DarkGate account creation sequence.
• Check for C2 network activity. Query Log360 for outbound network connections from the malware parent process in the period surrounding the account creation. Look for connections to external IPs or domains on non-standard ports or via HTTPS to newly registered or low-reputation domains. DarkGate's C2 connection typically precedes the account creation step, so connections in the 90 seconds before the alert are particularly relevant.
• Check for additional persistence mechanisms. DarkGate routinely establishes multiple persistence mechanisms beyond the rogue account. Query Log360 for scheduled task creation (Event ID 4698), registry Run key modifications (Sysmon Event ID 13), and startup folder file creation (Sysmon Event ID 11) on the same host in the same session window. These additional persistence entries must be removed during remediation.
• Assess credential exposure. DarkGate's information stealer component begins harvesting credentials shortly after execution. Determine the length of time the malware was active before detection and isolation. Identify all applications open or recently used during that window: browser sessions, email clients, VPN clients, and any other applications storing credentials. Treat all credentials accessible on the infected host during the infection window as compromised.
• Check for lateral movement indicators. If the rogue administrator account was created and DarkGate had time to use it before isolation, check for network logon events (Event ID 4624 Type 3) from the infected host to other internal hosts. DarkGate operators use the rogue local admin account for lateral movement when the host has network access to additional targets.

Escalation trigger

Escalate immediately to L3 if the rogue account was added to the local Administrators group; if C2 network connections from the malware parent process are confirmed; if additional persistence mechanisms beyond the rogue account were created; if credential harvesting activity is suspected based on the duration of infection before detection; or if lateral movement events from the infected host are identified. Isolate the host before completing the investigation if any of these conditions are confirmed.

Responding and remediating

Immediate containment

• Isolate the infected host from the network immediately using EDR host isolation or by disabling the network adapter. DarkGate's C2 channel provides the operator with live access to the host. Isolation terminates this channel and prevents lateral movement via the rogue administrator account.
• Disable and delete the rogue local user account created by DarkGate: net user <accountname> /delete. Verify the account has been removed by listing local accounts: net user. If the account has already been used to establish active sessions, terminate those sessions before deleting the account.
• Block the identified C2 IP addresses and domains at the perimeter firewall and DNS layer to prevent re-establishment of the C2 channel if the malware relaunches via a persistence mechanism before it is removed.

Forensic preservation

• Export the Windows Security event log and Sysmon operational log from the infected host covering the full period from the first unusual event to the time of containment. These logs contain the complete execution chain, account creation events, network connections, and any additional persistence mechanism creation events.
• Preserve the DarkGate dropper binary and any associated files in a forensic copy before removal. Hash all identified malware components using SHA-256 and submit to a threat intelligence platform or sandbox for analysis. The analysis may reveal the specific DarkGate variant, the operator configuration, and additional IOCs such as C2 domains and scheduled task names.
• If the infection was active for more than a few minutes before isolation, document the full list of applications and credentials that were accessible during the infection window. This list drives the credential rotation scope during eradication.

Eradication and recovery

• Remove the DarkGate binary and all associated files. Use the process tree identified during investigation to locate all files dropped by the malware, including the initial dropper, any secondary payloads downloaded via C2, and any configuration files written to disk.
• Remove all additional persistence mechanisms: delete any scheduled tasks created by the malware, remove any Run key entries, and clear any startup folder entries added during the infection. Verify each mechanism is removed and does not recreate itself after removal, which would indicate a persistence mechanism was missed.
• Force a mandatory password reset for the infected user account and for all accounts whose credentials were accessible on the infected host during the infection window. This includes browser-saved passwords, Windows credential manager entries, VPN credentials, and any cloud service credentials used from the host.
• Scan all other endpoints for the same DarkGate IOCs: the dropper file hash, the C2 IP addresses and domains, the rogue account name, and the scheduled task names identified during the investigation. DarkGate campaigns frequently target multiple users within the same organisation from the same campaign infrastructure.

False positive guidance

Net.exe user creation on a user workstation is an uncommon event in most managed environments. False positives are rare but occur in the following scenarios:

• IT provisioning scripts run locally: some IT teams use scripts that run locally on endpoints to create service or application accounts during software deployment. These scripts will run net user /add and will typically be invoked by a deployment tool such as SCCM, Intune Management Extension, or a similar agent. The parent process will be the deployment tool's agent binary in a documented system directory. Verify the script is documented, the parent process is a known deployment tool, and the account name matches the documented provisioning script output.
• Legitimate automation tools creating local accounts: some third-party software products create local user accounts during installation or configuration as part of their documented setup process. These will run net user /add from within their installer process, which should be in the product's installation directory and should be a signed vendor binary. Verify the installing binary is signed by the expected vendor and the account name matches the product's documentation.
• Developer or test environment account setup: in development or test environments, developers may manually create local accounts using net user /add for testing purposes. These will run interactively from cmd.exe or PowerShell, not from a suspicious parent process. Verify the account is in a documented development or test environment, the parent process is an interactive shell, and the action aligns with a development task.

Key differentiator

Legitimate net user /add executions on endpoints originate from known, signed deployment tool processes or from an interactive command prompt session run by a named administrator. The parent process will be in a documented system or application directory, not in AppData, Temp, or a user Downloads folder. DarkGate-initiated account creation will always have a parent process that is either an unknown binary, an AutoIt-compiled executable, or a LOLBin such as msiexec.exe or wscript.exe running from a user-writable path. Any net user /add command whose parent process is in a user-writable directory should be treated as malicious until positively attributed to a documented, authorised process.

Hardening and prevention

The following controls reduce the risk of DarkGate infection and limit the impact if a delivery attempt succeeds:

• Deploy advanced email filtering with attachment sandboxing and link scanning. DarkGate is frequently delivered via phishing emails. An email security gateway that dynamically detonates attachments and follows links to assess destination page content before delivery significantly reduces the delivery success rate.
• Block or alert on execution of binaries from user-writable paths (AppData, Temp, Downloads) via AppLocker or WDAC policies. DarkGate's dropper and its AutoIt-compiled payloads execute from these directories. Preventing execution from user-writable paths breaks the execution chain before the malware can establish C2 or create persistence.
• Restrict the parent processes that are permitted to spawn net.exe on user endpoints via AppLocker child process rules or WDAC policies. On a typical user workstation, net.exe should only be spawned by cmd.exe, PowerShell, or documented deployment tools, not by AutoIt, msiexec outside of documented installs, browser processes, or Office applications.
• Enable Windows Defender Attack Surface Reduction rules, specifically the rules that block Office applications from creating child processes, block all Office applications from injecting code into other processes, and block executable content from email clients and webmail. These rules directly address DarkGate's primary delivery mechanisms.
• Conduct regular user awareness training that specifically covers the file-sharing platform lure technique. Train users to recognise that requests to install a viewer or player application from an external sharing link are a common malware delivery pattern, and to report such requests to IT security before proceeding.
• Implement DNS filtering to block connections to newly registered or low-reputation domains. DarkGate's C2 infrastructure frequently uses recently registered domains. DNS filtering that blocks resolution of domains registered within the last 30 days significantly increases the cost of operating DarkGate campaigns against the organisation.