SECUINFRA Falcon Team • 06.02.2026 | Incident Response

Clickfix and Infostealers served fresh off the grill

Content

The incident showcased in this article was detected by the SECUINFRA Cyber Detection & Response Center (CDRC) as part of an MDR alert. The Falcon Team contributed relevant findings about the malware for handling and mitigation. This case serves as a good example of a complex “Clickfix”-style attack chain with steganographic elements.

A website / shop specializing in barbeque guides and accessories that the user browsed to was identifed as the initial infection vector. While we were only able to recover a low-resolution screenshot of the page (the Clickfix payload was pulled shortly after the initial detection, likely by the threat actor themself), we can confirm that it was indeed a Clickfix prompt that delivered the first stage of the attack. The website was built on a WordPress content management system with an outdated WooCommerce plugin, which we suspect as the initial access vector of the attacker. They were able to modify the website contents, inserting the Clickfix prompt as well as invisible links for SEO-related campaigns. Prior to the publication of this article we notified the owner and adminstrator of this website about the compromise and they were quick to restore it to a clean state.

Figure 1: The compromised website with the Clickfix lure

Below you can see the Powershell commandline that was executed as part of the Clickfix scheme. A WScript payload is downloaded from a remote system, saved to disk and executed.

Figure 2: Stage 1 – The Powershell command delivered via the Clickfix lure

The downloaded script contains the second stage script, which is appended to a variable and lightly obfuscated through an inserted recurring string. The function “mysteriousProcess” (aptly named by the threat actor) is obviously “dead code” and not relevant to the payload decoding. In the portion of the script on the right the recurring string is stripped from the variable and the Powershell command in it is executed via a new process started via the Windows Management Instrumentation (WMI). Interestingly, the threat actor left a comment behind the ShowWindow property, which translates to “hidden window” from Portuguese.

Figure 3: Stage 2 – Contents of asd1.js (a.js written to disk)

The next Powershell stage is designed to retrieve an image from one of two Google Firebase links, carve out Base64 content from it to decode and reflectively load it via the System.Reflection.Assembly mechanism. The .NET loader then receives a reversed Github URL, likely containing an additional payload, more on that later.

Figure 4: Stage 3 – Decoded Powershell script

Below you can see the image downloaded from Google Firebase on the left and its contents displayed in a Hex Editor on the right. As defined in the Powershell code above, we can search for the BASE64_START marker in the file. The trained eye will quickly recognize by the beginning of the Base64 encoded payload (“TVqQA…”) that this is likely a Windows PE file, as expected.

Figure 5: image1.jpg with the steganographic payload (Base64 encoded PE file)

After extracting and decoding the payload from the image we can take a closer look to determine that it is a .NET executable, partially obfuscated with SmartAssembly, but the general functionality of the program is still easily traceable. This exact .NET loader has been spotted in other attack chains as well, e.g. via E-Mail as documented by Malware-Traffic-Analysis.net in early January 2026.

Figure 6: .NET-based Loader obfuscated with SmartAssembly

In Figure 7 you can see the portion of the code to which the Powershell script passes the parameters along with the Github payload URL. After the payload is downloaded and decoded, it is executed via the “Inject” function, so it does not need to be saved to disk. Depending on the passed parameter, the loader is also able to establish basic persistence via the Start Menu Startup folder.

Figure 7: .NET-based Loader executing the payload from Github

Again, as expected from investigating the decoding logic earlier, we can see that the payload staged on Github is Base64 encoded and reversed. Decoding it yields the final payload, a Windows PE executable compiled with MinGW.

Figure 8: Payload hosted on Github (Base64 encoded and reversed)

For the purposes of this article we will not be analyzing the final payload in detail, as it is not obfuscated and most of its logic is easily recognizable as Infostealer malware, seemingly internally referred to as “Evelyn”. It was previously analyzed by fellow researchers at TrendMicro, when it was distributed via a malicious Visual Studio Code extension in the same general timeframe as this incident. We just wanted to highlight that this Stealer is capable of exfiltrating cryptocurrency information, Browser contents, Messenger sessions (e.g. Whatsapp, Telegram) and credentials for WiFi networks as well as VPN and FTP services. Data is exfiltrated via HTTP and SMTP, you can find the C2 servers below.

Figure 9: Significant strings from the Evelyn infostealer binary

Indicators of Compromise

Network-based Indicators

185.113.8[.]55
5.181.157[.]172
wxqdcakvuv[.]com

Host-based Indicators

cb7180e324435e4c9126e573b3a1b3e3585af4325abbaa27c6445cdc24cc8388 - asd1.js
573507ffbef1dcbc354c0ae29c71051c8790b4bbd06d71ee6d68078862cf0ab4 - image1.jpg
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - .NET Loader
b0ff2921bbc16f5446c5bb808fc86f0097e98feee79ed175e01ec4a17c0158c0 - Evelyn Infostealer

Thank you for reading our article to the very end. If you enjoy our analysis and would like to stay up to day with our publications, consider following us on Linkedin! Stay safe 🙂

Share post on:

SECUINFRA Falcon Team • Autor

Digital Forensics & Incident Response experts

In addition to the activities that are the responsibility of customer orders, the Falcon team takes care of the operation, further development and research of various projects and topics in the DF/IR area.

> all articles