Introducing the Aur0ra Ransomware Group

The BHIS ActiveSOC team recently responded to an incident that we have attributed to the Aur0ra ransomware group. In this incident, initial access was gained through vishing following aggressive email bombing. This foothold was followed up by the deployment of a unique C2 mechanism with noisy lateral movement & ransomware attempts.

About Aur0ra

Aur0ra first reportedly surfaced at the end of April 2026 and is tracked as a double-extortion group. We came across CYFIRMA's write-up on them during the response itself, which is what helped give us a name to work with.

Ransomware.live currently lists 28 victims across 10 countries, with an average of around 12 days between the intrusion and the victim being extorted on their blog.

We attributed the incident to Aur0ra based on the locker. The ransom note dropped across affected systems was named !!!README!!!DO_NOT_DELETE.txt, matching what's recorded for the group, and its contents followed their known template down to the phrasing and the per-victim access key. The encryption behavior lined up too, with files encrypted in place and no extension appended.

However, one thing we couldn't find reported anywhere was the tunnel. Most of the intelligence on the group focuses on the locker, and as far as we can tell this is the first documented case of Aur0ra using Xray-core for command and control.

Initial Access

Multiple users in the victim organization were impacted by aggressive email bombing, with some users suffering as many as 900+ emails. The victims then received a phone call from the “IT Helpdesk” to help them deal with the issue, allowing the threat actor to gain control over the machines.

Command and Control

The C2 channel was one of the most interesting parts of this engagement. The threat actor utilized Xray-core (https://github.com/xtls/xray-core), a legitimate open-source proxy and tunneling platform, and renamed it to blend in as benign software.

We observed the same Xray build under two notable disguises: a fake Chrome updater named ChromeUpdate.exe and a fake Windows connectivity component named ConnectivityHost.exe, which the attacker placed under ProgramData and user AppData paths respectively.

A reverse tunnel for C2, even renamed, isn’t by itself anything unique, but what was particularly fascinating was how the C2 tunnel tried to disguise itself.

With the above runtime configuration file, Aur0ra configured Xray to use browser-like TLS camouflage. The recovered VLESS/REALITY configuration set the TLS serverName to dl[.]google[.]com (a legitimate Google domain) and selected a Chrome TLS fingerprint. That made the ClientHello resemble Chrome traffic, while the real destination IP and owning process remained visible.

Interestingly, we also observed the tunnel making periodic burst connections to legitimate Google infrastructure over HTTP, alongside DNS lookups for www.google.com. This could be consistent with a connectivity check, but whether that was deliberate or incidental, the effect is the same: a process named ChromeUpdate.exe regularly talking to Google could be consistent with the threat actor making further attempts to disguise the traffic.

The beacon maintained its own persistence in two ways. First via Scheduled Tasks that executed the Xray binaries directly, but secondly, via a Run value which would execute a PowerShell script named updater.ps1, which carries its own copy of the beacon config and is used to relaunch the tunnel.

Simply killing a malicious process like this would have proved insufficient; full remediation of this mechanism required disruption of any active tunnels, removal of associated Run values, removal of any associated scheduled tasks, and finally deletion of any maliciously abused binaries or scripts.

Lateral Movement

Lateral movement in this event was highly noisy. Affected workstations issued roughly 10,000 outbound connections each via SMB, LDAP, WinRM, RDP, and RPC.

The C2 tunnel itself carried WinRM sessions, and the attacker proceeded to attempt to escalate privileges by executing net group "Domain Admins" <account> /add /domain on a number of hosts. This attempt proved unsuccessful across observed telemetry.

The threat actor then modified an existing drive-mapping GPO, adding a scheduled task named DriveMap-PolicyVerify. That task ran net user <admin-account> <password> /domain, an attempt to reset the password on an existing high value account. Every recovered task completion returned a nonzero result, and these attempts as well proved unsuccessful across the observed telemetry.

However, the threat actor was able to eventually gain control of a high-privilege administrator account, and evidence of its malicious use began appearing across the environment.

Anti-Forensics & Defense Evasion

After acquiring a higher privileged account, the threat actor began performing various anti-forensics and defensive evasion techniques. To start with, hundreds of log channels were cleared from multiple systems. The attacker then checked their work, making several wevtutil qe calls against a number of log channels, reading out the last few entries of each log, to confirm if the log clearing was successful.

The attacker then systematically dismantled Windows Defender on the host they used to execute the ransomware, in the minutes before detonation. Tamper protection was flipped, real-time monitoring and script scanning were disabled, and cloud sample submission and block-at-first-seen were turned off.

As part of the investigation it was also discovered that the attacker had timestomped their tunnel binaries, setting the created, modified, and accessed timestamps to an identical value on 2026-01-01.

Impact

The next stage was carried out by the threat actor through hands-on-keyboard operations, with the malware being copied into C:\Users\Public\Music\ via explorer.exe in an interactive session. One minute later a target list was written and saved.

The actual impact began with the distributor, dist.exe, which was pointed at the list of shares, and followed by the execution of the locker against C:\root in tandem with issuing vssadmin delete shadows /all /quiet and vssadmin resize shadowstorage /for=C: /on=C: /maxsize=401MB commands. A ransom note was then dropped on affected machines and was named !!!README!!!DO_NOT_DELETE.txt.

The locker itself was named after the victim organization, e.g. <victim_name>.exe, and looked to be custom tooled per organization. We identified the full usage strings from that locker variant that was deployed, which allows for custom encryption percentages, ESXi support, and other flags:

Usage: ./encrypter [OPTIONS]
Mode: ENCRYPT (compiled-in)
  -path <folder>       Path to a single folder to process (default: all disks / root directory)
  -percent<N>          Percentage of file to encrypt (0-100) (default: 0 = auto based on file size)
  -f<N><K|M|G>         Maximum file size to process (default: 0 = no limit)
  -threads <N>         Force worker thread count (default: auto = cores*2)
  -scanners <N>        Force scanner thread count (default: 4)
  -noparallel          Disable multi-threaded single-file encryption
  -esxi                ESXi mode: encrypt only VM files (vmdk,vmx,vmsd,vmsn,nvram,vmem,vswp,log)
                       Skips system volumes (BOOTBANK*, OSDATA*)
  -nohyperv            [Windows] Skip Hyper-V VM shutdown
  -extensions <list>   [Windows] Only process files with these extensions
  -allowfolders <list> [Linux] Include system folders

Notably, the locker encrypts in place, meaning files are not renamed and no extension is appended. What it does leave is a footer on every encrypted file, carrying the magic value 66 18 a7 2f and an RSA-wrapped per-file key. That footer was how we confirmed encryption, and with no extension to key on, it is the only reliable marker that a file has been touched.

Conclusion

This was one of those incident response engagements that can require a team to juggle multiple parallel investigations, especially when confronted with extensive lateral movement and significant effort put into anti-forensics.

What really stood out though was the beacon through Xray-core. A reverse tunnel isn't a new idea, but the lengths the attacker went to in disguising its traffic were fascinating, and that's what made it worth pulling apart.

Appendix A: Detection Mechanisms

We've included two Sigma rules below. The first catches Xray-family execution generally, keying on either the invocation grammar or the binary name. The second narrows that same pattern to binaries running out of user-writable paths, which is the renamed and hidden case we saw here.

Xray-core or V2Ray Proxy Execution

title: Xray-core or V2Ray Proxy Execution
id: a3460e8b-74bc-4cd0-ab43-4ea413f7acee
status: experimental
description: |
    Detects Xray-core and V2Ray-family VLESS tunnel clients by their launch syntax.
    The command-line shape holds regardless of what the binary gets renamed to.
references:
    - https://github.com/XTLS/Xray-core
    - https://xtls.github.io/en/config/transports/reality.html
author: BHIS ActiveSOC
date: 2026-08-12
tags:
    - attack.command-and-control
    - attack.t1572
    - attack.t1090
logsource:
    category: process_creation
    product: windows
detection:
    selection_behavioural:
        CommandLine|re: '^(?:"[^"]*"|[^"\s]*)\s+run\s+--?c(?:onfig)?[\s=]+(?:"[^"]*\.(?:json|ya?ml|toml)"|[^"\s]*\.(?:json|ya?ml|toml))'
    selection_known_name:
        Image|endswith:
            - '\xray.exe'
            - '\v2ray.exe'
    filter_main_aws_xray:
        Image|startswith: 'C:\Program Files\Amazon\XRay\'
    condition: 1 of selection_* and not 1 of filter_main_*
fields:
    - Image
    - CommandLine
    - ParentImage
    - User
    - Hashes
falsepositives:
    - Authorized Xray-core, V2Ray or sing-box deployments
    - AWS X-Ray daemon, excluded above by install path
level: medium

Renamed Xray-core Proxy Executing From User-Writable Path

title: Renamed Xray-core Proxy Executing From User-Writable Path
id: e3998a48-3f10-4d92-8c40-46e424fa1a03
status: experimental
description: |
    Detects a binary launching with the Xray-core invocation grammar from ProgramData
    or a user AppData directory. The rule keys on the argument pattern rather than the
    executable name, since the binary name can be attacker-chosen.
references:
    - https://github.com/XTLS/Xray-core
author: BHIS ActiveSOC
date: 2026-08-12
tags:
    - attack.defense-evasion
    - attack.t1036.005
    - attack.command-and-control
    - attack.t1572
logsource:
    category: process_creation
    product: windows
detection:
    selection_cli:
        CommandLine|re: '^(?:"[^"]*"|[^"\s]*)\s+run\s+--?c(?:onfig)?[\s=]+(?:"[^"]*\.(?:json|ya?ml|toml)"|[^"\s]*\.(?:json|ya?ml|toml))'
    selection_path:
        Image|contains:
            - '\ProgramData\'
            - '\AppData\Local\'
            - '\AppData\Roaming\'
            - '\Users\Public\'
    condition: all of selection_*
fields:
    - Image
    - CommandLine
    - ParentImage
    - User
    - Hashes
falsepositives:
    - Legitimate portable proxy tooling installations
level: high

Appendix B: Indicators of Compromise

Xray tunnel

Filenames like ChromeUpdate.exe, ConnectivityHost.exe, and config.json are not reliable indicators on their own. The significance was that these were malicious binaries masquerading as legitimate software.

Ransomware artifacts