BlackSuit Ransomware: VPN Brute-Force Attack Chain, TTPs, and IOCs from a 9-Day Intrusion

By the Proven Data DFIR Team. Analysis led by Abdullah Yasin, DFIR Engineer. Reviewed by Magdy Abdelaziz

BlackSuit is a ransomware operation that emerged in 2023 as a rebrand of the Royal ransomware group, itself an offshoot of the Conti ransomware lineage. Royal activity wound down as BlackSuit appeared; the two operations did not overlap. BlackSuit runs a double-extortion model: data is stolen first and threatened with publication on a leak site, then systems are encrypted. Its documented targeting spans multiple sectors and geographies, including critical infrastructure.

This article breaks down a real intrusion that Proven Data's DFIR team investigated and attributed to BlackSuit operators with high confidence. It is a standalone reference for incident response teams, MSPs, and security decision-makers who want the attack chain, the MITRE ATT&CK mapping, and the indicators of compromise in one place.

BlackSuit ransomware at a glance

Fields marked "not specified in this report" reflect what this engagement's evidence supports, not the full scope of BlackSuit's documented capabilities.

Case study summary

Proven Data's DFIR team identified the following behavior during the engagement and, based on the indicators below, attributed the intrusion to BlackSuit ransomware operators with high confidence:

• BlackSuit operators gained initial access through a password-guessing campaign (T1110.001) against a VPN account protected by a password alone, with no multi-factor authentication (MFA). The failures ran for three days before the first successful login; the actor then worked through external remote services (T1133) from Panama-, Canada-, and Russia-based infrastructure before pivoting to an address previously attributed to BlackSuit operations.
• The actor established persistence with the redicrt_x64.exe backdoor, registered under a registry RUN key and launched through a hidden PowerShell invocation (reproduced verbatim below), reinforced by service creation and the continued use of compromised accounts.
• Credential access combined Mimikatz LSASS dumping, a remote registry dump tool (flagged as Behavior:Win32/RemoteRegDump.A), pass-the-hash over NTLMv2, and environment-wide brute-force waves launched from weaponized internal servers that generated tens of thousands of logon attempts.
• Ahead of encryption, the actor disabled Windows Defender real-time protection across the network, visible as Security event 5001, and operated hands-on-keyboard over RDP using signed Windows binaries only.
• Data was staged with WinRAR using a deliberate install-use-remove pattern; exfiltration is assessed as likely rather than confirmed. The file.exe BlackSuit binary then encrypted multiple systems, with execution corroborated by Amcache, SRUM, and Windows Error Reporting artifacts.
• Who should care: any organization exposing VPN remote access without MFA, and any environment relying on Windows Defender as its only endpoint control. Nine days elapsed from the first brute-force attempt to enterprise-wide encryption.

MITRE ATT&CK mapping

Confidence values: Observed = directly evidenced by forensic artifacts; Probable = consistent with the evidence but not independently confirmed. See MITRE ATT&CK's technique reference for full technique definitions.

Attack chain at a glance

The campaign progressed from VPN brute force to enterprise-wide encryption over nine days. The figure below maps the chain: external infrastructure driving brute force and logins against the VPN gateway, RDP fan-out from VPN-assigned addresses into the network, and the final encryption wave.

The day-by-day progression, expressed as relative days from the first observed brute-force attempt:

Attack lifecycle: phase-by-phase breakdown

The lifecycle below follows the order the DFIR team reconstructed the evidence in: from the first brute-force packet to enterprise-wide encryption nine days later.

Phase 1: Initial Access: VPN brute force without MFA

The intrusion began with a password-guessing campaign against a VPN account at the perimeter gateway. The first recorded failures came on Day 0, 02:26 UTC, when the gateway logged multiple failed login attempts for the targeted account from a Russia-based address; they marked the start of the campaign. The gateway logged repeated sslvpn_login_permission_denied events over three days from multiple Russia-based source addresses:

sslvpn_login_permission_denied remip 94[.]232[.]46[.]45

sslvpn_login_permission_denied remip 5[.]181[.]86[.]158

sslvpn_login_permission_denied remip 5[.]181[.]86[.]65

sslvpn_login_permission_denied remip 5[.]181[.]86[.]185

sslvpn_login_permission_denied remip 92[.]255[.]85[.]43

sslvpn_login_permission_denied remip 85[.]234[.]216[.]197

sslvpn_login_permission_denied remip 85[.]234[.]216[.]195

The failures are consistent with password guessing (T1110.001). The gateway denied each attempt, but the denials did not interrupt the campaign; the guessing continued for three days until credentials succeeded.

The first account to fall was not the one under initial attack. On Day 2, between 13:58 and 14:19 UTC, the gateway logged successful VPN logins for a second account from the Panama-based address 45[.]227[.]254[.]43 and then the Canada-based 66[.]70[.]179[.]236 (operated within AS 16276, OVH SAS), with session lines recording tunnel establishment and teardown:

• tunnel up
• login successfully
• lost connection
• idle timeout
• DTLS tunnel established
• remip 45[.]227[.]254[.]43
• remip 66[.]70[.]179[.]236

Geolocation identifies infrastructure, not actor location. The Canada-based address had been flagged as malicious by 2 of 94 security vendors at the time of analysis, with the last analysis approximately 24 days before the intrusion. The same account's logs also recorded failed logins (sslvpn_login_permission_denied) from two further external addresses, 185[.]190[.]24[.]181 and 80[.]94[.]95[.]16; the gateway denied each of those attempts, and neither address produced a session.

On Day 3 the actor completed the compromise of the originally targeted account. Primary VPN connectivity was established on Day 3, 01:00 UTC, and the session lines recorded a DTLS tunnel, a successful login, and a lost connection from 94[.]232[.]46[.]204 at 01:58:31 UTC:

• DTLS tunnel established
• login successfully
• lost-connection
• remip 94[.]232[.]46[.]204

The address 94[.]232[.]46[.]204 was geolocated to Russian infrastructure and had been previously associated with malicious activity; the same caveat applies, geolocation identifies infrastructure, not actor location. A session termination was followed by immediate reconnection at 10:58 UTC the same day. Later on Day 3, between 01:02 and 02:34 UTC, the actor pivoted to 5[.]181[.]234[.]58, an address previously attributed to BlackSuit ransomware operations through threat-intelligence correlation; the same window saw WinRAR installation and an RDP authentication using a compromised service account.

These logons match T1133 (External Remote Services) with T1078 (Valid Accounts). The accounts authenticated with passwords alone: no MFA challenge protected the VPN, so the guessed credentials succeeded without a second factor.

Phase 2: Discovery: non-existent-account probes and network scanning

On Day 2 the actor probed the network from VPN-assigned addresses with coordinated authentication attempts against accounts that did not exist in the environment. The attempts returned "User does not exist" failures across more than 20 systems, a pattern consistent with T1018 (Remote System Discovery), identifying reachable systems and their authentication behavior without valid credentials. Two scanning waves were observed on Day 2: one at 11:55 UTC and a second between 16:08 and 16:12 UTC, each reaching more than 20 systems. The three probing identifiers are adversary-side artifacts, not victim accounts:

• desktop-ggl6e8t\r7
• tcig\cking
• desktop-mfsdkam\jack

The desktop-* names pair a desktop-style machine prefix with a short username, consistent with automated scanning rather than interactive use. On one server the recorded window for the second wave carries an open evidence contradiction: one part of the evidence places the attempts between 16:08:50 and 16:09:21 UTC, while another places them between 16:11:59 and 16:12:28 UTC; the ten-second window from 16:12:00 to 16:12:10 UTC is corroborated. The range is presented as approximately 16:08 to 16:12 UTC, and the discrepancy remains open. Every logon attempt in the scanning waves was denied and recorded; the denials did not interrupt the probing.

On Day 7, 14:11 UTC, failed authentication attempts targeted a domain administrator account from a VPN-assigned address, presenting invalid credentials; the logons were denied and no access resulted, a positive failure observation showing the guessing still reaching for privileged accounts between the early scanning and the final phase.

Later, Advanced IP Scanner, a network-scanning utility that enumerates live hosts and open services, was executed from C:\Temp under a compromised account on Day 4, 00:20:16 UTC, the artifact string reading C:\temp\Advanced IP Scanner 2.5.594.1. The execution location was anomalous and its attribution to the actor remained unresolved; it is reported here as an unresolved observation consistent with T1046 (Network Service Discovery). During the collection phase the actor also ran targeted file and directory discovery (T1083): on Day 8, between 02:31 and 03:50 UTC, access to two servers targeted HR documentation, employee photos, and approval records, locating sensitive business data sets for staging.

Phase 3: Execution: hands-on-keyboard over RDP with signed binaries

Command, scripting, and administrative execution took place inside interactive RDP sessions under compromised accounts. Process-creation records in the session telemetry showed the actor driving clusters of legitimate Windows utilities under each session's account context on the deployment day. In one session on a server, under a compromised domain administrator account connecting from a VPN-assigned address on Day 8, 07:30:21 UTC, the actor spent the following hour launching a timed sequence of utilities:

• explorer.exe at 07:30:35 UTC
• wscript.exe at 07:30:38 UTC
• servermanager.exe at 07:31:44 UTC
• iexplore.exe at 08:27:00 and 08:27:25 UTC
• applicationframehost.exe at 08:28:05 UTC
• cmd.exe at 08:29:51 UTC

In a second session on another server, under a second compromised domain administrator account connecting from the same VPN-assigned address on Day 8, 09:38:46 UTC, the actor executed a dense set of signed Windows utilities between 09:39 and 10:05 UTC: explorer.exe, applicationframehost.exe, cmd.exe, mmc.exe, msiexec.exe, servermanager.exe, taskmgr.exe, and wscript.exe. The composition (command shells, scripting interpreters, an installer, and administrative consoles) is consistent with hands-on work rather than a single automated payload, and maps to T1059.003 (Windows Command Shell) and T1218 (Signed Binary Proxy Execution), a living-off-the-land pattern that blends into normal administrative activity.

The presence of msiexec.exe is consistent with installing tooling or modifying configurations from within the session, and servermanager.exe provides domain-wide configuration visibility from a single console. On a third server, endpoint telemetry recorded Microsoft Management Console (mmc.exe), an administration shell that can be used to tamper with Windows policies and modify system security settings, executed on Day 8, 05:46:12 UTC under a compromised domain administrator account inside a malicious RDP session; the same class of mmc.exe policy-tampering activity was observed on a second host the same day, and the Defense Evasion section cross-references the pattern.

Phase 4: Persistence: the redicrt_x64.exe RUN-key backdoor

The primary persistence mechanism was the redicrt_x64.exe backdoor, configured to execute automatically at user logon through the registry RUN key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (T1547.001). On Day 5, 19:22:07 UTC the actor installed the binary on a server and registered the autorun under a compromised domain administrator account; registry artifacts captured the RUN-key entry, execution telemetry recorded the launching command, and a configuration change followed three seconds later at 19:22:10 UTC. The launching command was a hidden PowerShell process (T1059.001), reproduced verbatim:

powershell.exe -windowstyle hidden -Command '&'C:/Windows/redicrt_x64.exe'

The same pattern repeated during the encryption phase on a second server: on Day 8, 02:42:39 UTC the binary executed from C:\temp\redicrt_x64.exe, and at 02:42:47 UTC it was added to the same RUN key via PowerShell, under the same domain administrator account. Both installations shared the same evidence classes: the registry RUN-key artifact, the PowerShell install command, and matching execution timestamps.

The actor reinforced the foothold with service creation (T1543.003) and further registry modifications, and, most durably, through the continued validity of numerous compromised accounts, including multiple domain administrators and service accounts (T1078). This RUN-key-plus-hidden-PowerShell pattern matches BlackSuit's documented persistence tactics and contributes to the intrusion's attribution.

Phase 5: Privilege Escalation: pass-the-hash and a UAC-bypass attempt

Because the compromised VPN accounts carried ordinary user privileges, domain-administrator access did not follow from initial access alone; the actor reached it through staged compromise of service accounts and domain administrators, the kind of identity-layer escalation that identity threat detection is built to catch before it reaches a domain controller. Across Day 6 and Day 7 the actor ran a privilege-escalation campaign against the environment's domain controllers and servers, mounting repeated brute-force attempts against service accounts; authentication event logs recorded the failed attempts against the service-account tier, the principal target being the service account whose compromise underpinned the escalation. Two techniques evidence the Privilege Escalation tactic directly:

• Pass the Hash (T1550.002): on Day 8, 05:34 UTC, an authentication log flagged a pass-the-hash attack from a VPN-assigned address against a compromised domain administrator account using NTLMv2 authentication, followed immediately by a new logon session for that account from the same address. The alert fired while the activity was underway and did not interrupt it.
• Bypass User Account Control (T1548.002): on Day 8, 05:14 UTC the actor authenticated over RDP under a compromised domain administrator account from a VPN-assigned address, establishing multiple sessions for two domain administrator accounts from the same address; one minute later, at 05:15 UTC, endpoint telemetry recorded a suspicious explorer.exe task created with the /nouaccheck parameter, an invocation assessed as an attempt to bypass UAC.

Earlier in the same minute sequence, at 05:16 UTC, endpoint telemetry flagged the BlackSuit binary file.exe executing under a second compromised domain administrator account, with concurrent mmc.exe activity accessing mmcndmgr.dll; the detection fired during the deployment, and whether it interrupted the binary on that host remained unresolved.

The same period saw the installation of DameWare Mini Remote Control, a legitimate remote system-access tool. The evidence shows the installation alone, so it is treated as an installed capability rather than a mapped technique.

Phase 6: Defense Evasion: the event-5001 disabling wave

On day 8, Ahead of the enterprise-wide encryption wave, the actor systematically disabled Windows Defender real-time protection across the network (T1562.001, Impair Defenses). The Windows Security log recorded event 5001 (real-time protection switched off) on 8 servers across the network including the domain controller between 04:33:00 UTC and 10:46:30 UTC, all on the deployment day.

Every event-5001 record preceded the start of encryption on its host. No automated response was triggered; real-time protection remained off as the ransomware deployed. This systematic, network-wide disabling ahead of encryption reflects a defense-evasion pattern documented in prior BlackSuit activity and factors into the intrusion's attribution.

On the fourth server in that list the disable at 08:21:02 UTC was concurrent with a cluster of ransomware-behavior alerts (Behavior:Win32/Ransomware!NoteStr.A, Behavior:Win32/GenRansomNote.SA, Behavior:Win32/GenRansom.SA!rsm and Behavior:Win32/GenRansomNote.SB) spanning 06:10 through 08:51 UTC, fired while deployment was in progress. The payload executed after protection had been neutralized, so the alerts did not halt it.

Throughout the final-phase sessions the actor relied exclusively on legitimate, signed Windows binaries from normal system locations (cmd.exe, explorer.exe, applicationframehost.exe, msiexec.exe, mmc.exe, servermanager.exe, wscript.exe, taskmgr.exe), a living-off-the-land pattern (T1218) that blended the activity into standard system behavior. In at least one case the actor used mmc.exe to modify audit policies on a workstation.

Phase 7: Credential Access: dumping, guessing, and weaponized internal hosts

The actor obtained credentials by two complementary means: harvesting from compromised hosts, and password guessing at scale, much of it launched from the environment's own compromised servers, which were converted into attack infrastructure.

Credential harvesting

Mimikatz was executed on multiple hosts, including a domain controller, under a compromised domain administrator account (T1003.001, LSASS Memory). The timing shows immediate operational re-use: an RDP logon from the same VPN-assigned address followed the domain-controller dump by ten seconds. An earlier Mimikatz run on one of the first compromised servers revealed a previously unknown compromised domain account, which the actor subsequently used for RDP access. A third Mimikatz execution was recorded on another server under a compromised user account; that same server carried the Advanced IP Scanner execution analyzed in the Discovery section.

The harvesting extended to registry secrets. Within the same morning window of the final phase, Windows Defender flagged the Remote Registry Dump Tool (Behavior:Win32/RemoteRegDump.A, Severe) on hosts across the network (T1003.005):

• a domain controller: Day 8, 05:37:54 UTC, one minute after a logon under the compromised domain administrator account from a VPN-assigned address, indicating the harvesting rode the lateral-movement session
• a second domain controller: Day 8, 05:35:38 UTC
• a server: Day 8, 05:35:30 UTC
• the server that served as the environment-wide brute-force platform: Day 8, 05:36:41 UTC
• another server: Day 8, 05:36:00 UTC, where the evidence recorded registry dumping from C:\Windows\System32\svchost.exe
• a further server: Day 8, within the same morning window

The detections fired while the credential-harvesting wave was running; whether any alert interrupted the dumping on its host remained unresolved.

The harvested and guessed credentials were re-used across the network, and the re-use was not flawless. One server recorded a failed RDP attempt under a compromised domain administrator account from a VPN-assigned address on Day 6, 03:46:48 UTC, rejected because the password was incorrect; the failure is a positive observation, showing the actor re-trying credentials that did not yet work on that host. Elsewhere the re-use succeeded: the domain account revealed by the earlier Mimikatz dump logged on over RDP from a VPN-assigned address on Day 8, and on another server successful logons under a compromised domain administrator account followed earlier failed attempts.

Brute-force campaigns from weaponized hosts

Internal guessing ran at scale (T1110.001/.002/.003), campaign by campaign:

• An environment-wide campaign against a domain account, launched from a VPN-assigned address beginning between 17:47 and 18:06 UTC on Day 8 and running into the early hours of Day 9, reached more than 30 hosts.
• A concentrated campaign against a service account ran from a weaponized internal server, Day 6, 20:57 UTC through Day 9, recording hundreds of failed logons per host across the network.
• One server recorded ~11,000 attempts against a single domain administrator account from an unidentified source across five days, Day 3, 12:00 UTC to Day 8, 12:16 UTC.
• Compromised servers were weaponized against user accounts: one directed ~6,500 attempts at a single account inside a two-hour window on Day 8 (10:25 to 12:36 UTC), and two others generated a cumulative ~27,000 failed attempts against a second account; the volume itself is the notable tradecraft fact.
• The guessing extended to a backup service account holding domain-administrator privileges, to domain administrator accounts (some failing because the account was disabled), and to local accounts.
• One server absorbed ~3,700 failed attempts against corp\admin, a non-existent administrative account, over a span of sixteen days, Day -6, 10:38 UTC to Day 10, 11:40 UTC; every attempt failed because the account did not exist, and the window's pre-campaign days make the series an anomaly, with guessing against this account predating the intrusion's Day 0.

Phase 8: Lateral Movement: RDP fan-out from VPN-assigned addresses

Lateral movement ran over RDP and non-interactive network logons using the compromised accounts (T1021.001, T1021.002, T1078.001). Sessions began on Day 3, spread steadily, and peaked on the deployment day, when session records show dozens of connections reaching more than 20 hosts in a single day. The majority originated from a single VPN-assigned address that acted as the dominant RDP source for the campaign, with several other VPN-assigned addresses appearing as secondary sources.

Several patterns stand out as detection leads:

• Service accounts used interactively. Service accounts exist for automated, non-interactive use; interactive RDP logons under them, including on a domain controller, indicate the credentials were held and used by the actor.
• High-volume authentication telemetry. On one server the authentication logs recorded more than 300 successful authentications from a VPN-assigned address under a compromised domain administrator account, ending on Day 9, 11:45:11 UTC, indicating extensive lateral movement. On another server the telemetry identified more than 3,000 authenticated logon events arriving from a second internal server under a third compromised service account between Day 8, 17:40:22 UTC and Day 9, 14:20:55 UTC, an account the campaign had not otherwise surfaced, compromised and used for lateral movement.
• Intermediary hosts. One server received domain-admin sessions from the dominant VPN-assigned address and then served as the source for onward connections to a second server and a domain controller: a classic pivot chain.
• Loopback-style sources. On one host, successful RDP logons under a domain administrator recorded the connection source as the local host itself, a pattern usually tied to RDP through remote tunneling; it remains a candidate pivot technique.
• Staged PSExec. The PSExec service binary psexesvc.exe was staged on two domain controllers, identified at C:\Windows\PSEXESVC.exe on one and under SYSVOL\Windows\PSEXESVC.EXE on the second; neither record carried an execution timestamp, so the capability is reported as prepared rather than executed, consistent with the domain controllers serving as pivot points.
• A scanning source returns. On one domain controller, failed logon attempts against ten domain accounts originated from a source named desktop-ggl6e8t between Day 8, 15:22:02 and 15:25:05 UTC, three minutes of failures in the same window as service-account and domain-administrator sessions on the host. The source name matches the Day 2 scanning identifier, tying the Day 2 reconnaissance wave to Day 8 activity on a domain controller.

Phase 9: Collection: WinRAR staging with install-use-remove discipline

From Day 3 through Day 8 the actor ran a staged data-gathering operation: sensitive business data on departmental shares was accessed, compressed with WinRAR, and concentrated on a small set of staging hosts (T1560.001 Archive Collected Data, T1074.001 Local Data Staging, T1005 Data from Local System).

The tradecraft details that defenders can hunt:

• The first RAR archives were created on Day 3 between 01:29 and 04:27 UTC on a server under a compromised service account, within hours of the pivot to BlackSuit-attributed infrastructure.
• On a legacy file server the operation concentrated between 00:05 and 04:52 UTC on Day 4: execution records showed the compromised service account executing WinRAR at 00:09:45 UTC, the archiver installed between 00:09 and 00:11 UTC, WinRAR.exe initiated at 00:41:43 UTC, and multiple RAR archives accessed from 00:12 UTC on Day 4 through 13:14 UTC on Day 5.
• On one staging server, WinRAR was installed, used, and removed inside a single working window: installed on Day 5, 20:09:20 UTC, used on Day 6, 08:31:51 UTC, and removed the same day at 10:08:19 UTC, a deliberate operational-security pattern that kept the tool resident only as long as the targeted data sets required and minimized the artifact trail.
• Data on one server was accessed through a separate staging host, a path suggesting familiarity with the network architecture. On the encryption day itself the same path carried a final pass: data on the data-source server was accessed between 03:00 and 08:24 UTC on Day 8 under a compromised domain administrator account, assessed as possible exfiltration-stage access distinct from the Day 4 through Day 6 staging.
• WinRAR artifacts appeared on an additional server during the final phase, assessed as a potential indication of further staging rather than a confirmed event.

Phase 10: Exfiltration: assessed likely, not confirmed

The assessment of likely exfiltration rests on the WinRAR artifacts, the systematic file-access patterns, and the deliberate staging described above; the actor had approximately three to four days of opportunity between the core collection window and the encryption wave. The use of legitimate credentials and a legitimate tool made detection difficult, and the methodical cleanup reduced the artifact trail; the full scope potentially exceeds the documented evidence. Based on the file-access patterns and WinRAR timing, the scope of potentially compromised data spanned three areas:

• business operations data: departmental file shares, administrative documents, and operational records
• infrastructure data: network configuration files, system documentation, and technical specifications
• sensitive business information: financial records, business planning documents, and internal communications

The behavior is mapped to T1048 (Exfiltration Over Alternative Protocol). Where exfiltration is assessed as likely rather than confirmed, organizations still need to work through the breach-notification implications alongside the encryption event; the two carry different legal and regulatory obligations.

Phase 11: Impact: file.exe, corroborated by Amcache, SRUM, and WER

On the final two days the actor executed the BlackSuit ransomware binary file.exe across multiple systems, creating readme.blacksuit.txt ransom notes and confirming encrypted-extension impact (T1486, Data Encrypted for Impact). Both the binary and the ransom-note filename are characteristic BlackSuit indicators. The binary is a 68,608-byte PE32 i386 executable. Because the environment lacked centralized logging, the executions were reconstructed from forensic artifacts, a case study in how to preserve and rebuild evidence when native logging falls short:

• Amcache recorded the binary's execution paths and times.
• SRUM captured repeated per-hour execution entries on several hosts (up to a dozen distinct entries on a single server across the deployment day), indicating repeated deployment attempts rather than single runs.
• WER crash dumps preserved the binary's termination events.

Crash events did not prevent impact: on multiple hosts the binary crashed or terminated unexpectedly, yet encrypted file extensions confirmed the encryption routine had at least partially succeeded. On one server two crash dumps were recorded on Day 8 at 07:24:08 and 07:24:10 UTC, two seconds apart, with encrypted files indicating partial success of the encryption routine. On one host, Defender's Ransom:Win32/Blacksuit.SA!MTB signature fired on Day 8, 04:53:30 UTC, seconds before the binary crashed at 04:54:04 UTC, and the evidence indicates Defender interrupted the encryption routine, yet encrypted extensions were still confirmed there.

Most other signature detections fired during or after execution and prevented nothing: on a second host the signature fired on Day 8, 10:17:19 UTC, after file.exe had executed at 09:31:32 UTC; on a third host alerts fired on Day 8 at 09:21:31 and 09:21:52 UTC, after the execution at 05:12:25 UTC; and on the domain controller the signature fired on Day 9, 07:16:33 UTC, after the execution and after real-time protection had been disabled. On one server a scheduled antivirus scan on Day 9, 17:03:00 UTC detected and removed the binary; the removal came after the encryption phase and stands as the eradication evidence for this artifact, not a prevention.

On one host the evidence spanned execution, crash, and follow-up execution: Amcache recorded file.exe executing on Day 8, 00:10:32 UTC, crash-dump analysis recorded the binary terminating at C:\file.exe at 12:10:00 UTC, and SRUM recorded a further execution at 11:15:20 UTC under the SID matching the compromised domain administrator account. One record dated that follow-up execution outside the campaign window; the date was resolved as a typographical error for Day 8, a resolved evidence contradiction, so every execution on the host fell on Day 8.

Two deployment details are worth a defender's attention:

• SYSVOL staging: on one file server, file.exe executed with the original path SYSVOL\file.exe: the actor had staged the binary in the domain's own SYSVOL share.
• Network-based encryption: on one host, encryption artifacts were present without corresponding local execution artifacts, consistent with the encryption routine reaching the host over the network from another system.

Post-encryption activity continued into the following day: further deployment attempts, continued antivirus detections, persistent RDP access attempts, and network scanning.

Taken together, the redicrt_x64.exe persistence mechanism, the systematic Defender-disabling wave, the file.exe and readme.blacksuit.txt indicators, and the previously-attributed VPN infrastructure support high-confidence attribution to BlackSuit ransomware operators or their affiliates. The broader methodology, Mimikatz credential harvesting, domain-controller targeting, WinRAR-based staging, and living-off-the-land execution, aligns with documented BlackSuit operations reported by CISA and the FBI.

Responding to a BlackSuit intrusion

DO NOT PAY THE RANSOM. Decisions about ransom payment carry legal, operational, and financial consequences that should be assessed with qualified legal counsel and an incident response team before any response action is taken. If BlackSuit or similar tradecraft is active in your environment, follow a structured incident response plan and the core incident response actions: containment, evidence preservation, and credential rotation, in that order, before attempting recovery. Proven Data's DFIR team, including the practitioners who investigated this intrusion, is available for 24/7 incident response if BlackSuit or comparable tradecraft is active in your environment.

Detection and mitigation guidance

Generic, defender-actionable guidance derived from the observed tradecraft:

1. Enforce MFA on all remote access, especially VPN gateways. Password-only VPN accounts are the single control failure that opened this intrusion.
2. Alert on VPN authentication anomalies: sustained sslvpn_login_permission_denied bursts, successes following failure bursts, and rapid source-geography changes for one account.
3. Alert on Windows Security event 5001 (Defender real-time protection disabled) and enable tamper protection. One event is a lead; several in a day is an incident.
4. Deploy EDR. An environment whose only endpoint control is Windows Defender is exposed the moment that protection is switched off.
5. Hunt persistence artifacts: RUN-key entries pointing at unfamiliar binaries, powershell.exe -windowstyle hidden command lines, and out-of-cycle service creation.
6. Protect and monitor credentials: enable Credential Guard/LSASS protection, alert on Behavior:Win32/RemoteRegDump.A-class activity, restrict remote registry access, and detect pass-the-hash usage of NTLM.
7. Watch service accounts: any interactive logon, especially RDP to a domain controller, by a service account should alert. Apply privileged-access workstations and tiered administration for domain admins.
8. Baseline authentication volume: single sources failing logons against many hosts, or thousands of failures against one account, indicate weaponized internal hosts.
9. Alert on archiver behavior: WinRAR installation on servers, RAR creation on file servers, and install-use-remove cycles within days.
10. Audit SYSVOL contents for unauthorized executables and monitor for psexesvc.exe on domain controllers.
11. Centralize logs and extend retention. In this intrusion, default logging gaps and log rotation forced reconstruction from Amcache, SRUM, and WER artifacts; those artifacts corroborate execution, but centralized telemetry would have shortened the detection timeline.
12. Modernize legacy systems and segment the network so that a single compromised credential set cannot reach domain controllers, file servers, and backup infrastructure alike. The root causes in this intrusion were structural: password-only VPN authentication combined with weak password policies let the guessing succeed; a substantial legacy operating-system population, including Windows Server 2008 R2 systems beyond end of life and production Windows Server 2012 and 2012 R2 systems nearing end of support, ran without EDR, leaving Windows Defender as the only endpoint control; and once that control was switched off, credential harvesting and lateral movement went undetected until the ransomware deployment.

Indicators of compromise

Validate and contextualize every entry against local telemetry before blocking. The victim-specific negotiation identifier in the ransom-note URL is redacted (see the appendix).

Network indicators

File and registry indicators

Tool-based indicators

Behavioral and account indicators

If any of these indicators appear in your environment, Proven Data's ransomware recovery team can help scope the intrusion and coordinate recovery.

Appendix: ransom note

The ransom note (readme.blacksuit.txt) created on encrypted systems, reproduced verbatim except for the victim-specific negotiation identifier, which is redacted. The note text is standard BlackSuit boilerplate observed across the group's victims; the data types it lists are the actor's generic claims, not evidence of what was actually staged or exfiltrated.

Good whatever time of day it is!

Your safety service did a really poor job of protecting your files against our professionals.

Extortioner named BlackSuit has attacked your system.

As a result all your essential files were encrypted and saved at a secure server for further use and publishing on the Web into the public realm.

Now we have all your files like: financial reports, intellectual property, accounting, law actions and complaints, personal files and so on and so forth.

We are able to solve this problem in one touch.

We (BlackSuit) are ready to give you an opportunity to get all the things back if you agree to make a deal with us.

You have a chance to get rid of all possible financial, legal, insurance and many others risks and problems for a quite small compensation.

You can have a safety review of your systems.

All your files will be decrypted, your data will be reset, your systems will stay in safe.

Contact us through TOR browser using the link:

hxxp://c7jpc6h2ccrdwmhofuij7kz6sr2fg2ndtbvvqy4fse23cf7m2e5hvqid[.]onion/?id=[REDACTED: victim-specific negotiation ID]