Fake ChatGPT Malvertising Campaign
Fake ChatGPT website used in malvertising campaign
ChatGPT has become one of the most recognised technology brands in the world, making it an attractive target for cybercriminals looking to exploit user trust. Threat actors frequently impersonate well-known software providers, and the growing popularity of AI tools has created new opportunities for malware distribution campaigns disguised as legitimate downloads.
Campaign overview
Evalian’s Security Operations Centre team recently discovered a ChatGPT malware campaign using a fake OpenAI download website promoted through sponsored search results. The campaign delivers platform-specific malware for Windows and macOS users and uses CAPTCHA verification, JavaScript obfuscation and staged execution techniques to evade detection.
In this blog, we examine the infrastructure behind the campaign, analyse the malicious Windows payload, and explore the techniques used to hinder detection, including JavaScript obfuscation, CAPTCHA-based execution controls and staged payload delivery. We also highlight the indicators and behavioural patterns defenders can use to identify similar threats and discuss what organisations can do to improve visibility and response capabilities when faced with increasingly convincing malware campaigns.
The fake ChatGPT website
Analysis of the Windows payload identified an Electron-based loader with obfuscated JavaScript, CAPTCHA gating, PowerShell process creation, and evidence of staged, event-driven execution. The malicious domain openew[.]app uses OpenAI and ChatGPT branding to lure the user into downloading a malicious executable disguised as a ChatGPT installer.
Figure 1: OpenAI Branded Fake Website
The domain has been flagged as malicious by multiple vendors on VirusTotal, with several detections linked to phishing activity and malware distribution. It also appears to have been recently registered using infrastructure registered with Namecheap Inc, with name servers under dns1.registrar-servers[.]com and dns2.registrar-servers[.]com, suggesting a newly created domain that was quickly deployed, often indicative of opportunistic malicious use.
Figure 2: Domain OSINT Results
Figure 3: Domain WHOIS Lookup
Infrastructure analysis
The associated IP address (144[.]172[.]104[.]205) resolves to RouterHosting LLC, a cloud infrastructure provider offering low-cost virtual private servers. This type of infrastructure is commonly used for rapidly deployed phishing and malware campaigns due to its affordability and ease of provisioning, which can make malicious activity harder to trace and take down quickly. Further indicating short-term use of malicious infrastructure is the passive DNS results showing multiple other malicious domains linked to this IP.
Figure 4: Passive DNS Results
Delivery mechanism and payload distribution
The website contains three download options for users: Windows, MacOS, and a Chrome extension. The extension links to a legitimate ChatGPT Search add-on, further reinforcing the site’s apparent authenticity.
Figure 5: Legitimate Chrome Extension
Figure 6: Windows File OSINT
The Windows file [56CC26E88C064B0C423AA8AD6530E58F91D1E4D28FAB1A8BCEDEF16A6582B4D2 (SHA256)] has been reported by 4 vendors at the time of analysis and initial analysis shows the installer using Inno Setup – an open-source installation builder used commonly by legitimate Windows products. At the time of analysis, the MacOS file [7E5B708F6659B1FAD3AAE7B589A706434FBF21708AEEC5AF5910189B96E25FEF (SHA256)] has not been flagged by any vendors.
Chat_GPT.exe static analysis
Initial static analysis identified several inconsistencies relating to the file’s identity and provenance. The sample is distributed as Chat_GPT.exe, suggesting an association with ChatGPT; however, the embedded file description identifies the application as PovariEGLESVapp Setup.
Furthermore, the executable is digitally signed by F.F.A.P. Hurkmans Beheer B.V., a publisher name that does not appear related to either ChatGPT or OpenAI. While Windows reports the digital signature as valid, code-signing certificates only verify the integrity of the file and the identity of the signer at the time of signing; they do not provide assurance that the software is legitimate or benign.
The combination of a misleading filename, inconsistent embedded metadata, and an unrelated publisher raises concerns that the executable may be attempting to masquerade as legitimate software.
Figure 7: Chat_GPT.exe File Information
Analysis using innounp identified the sample as an Inno Setup installer containing an Electron-based application. The extracted file structure includes LICENSE.electron.txt, multiple Chromium runtime components, and a resources\app.asar archive, alongside App.exe and various supporting .dat, .dll, and .pak files. The presence of these artefacts indicates that the installer functions primarily as a packaging and deployment mechanism for a Chromium/Electron application rather than a native Windows (e.g., Delphi-based) installer.
The primary executable, App.exe (SHA-256: D9AD44D43E57B870793FA5CF7FB3A813990D0CBD0C7087BDE70A5E61FB1F1FE6), was also present in the extracted payload. At the time of analysis, the file is unsigned and has been flagged by at least one antivirus engine under the heuristic label “fantasy,” suggesting possible repacking or generic heuristic detection rather than a definitive malware family classification.
Static analysis of App.exe through string extraction did not reveal evidence of direct system-level command execution, such as PowerShell or CMD invocation. This difference between static and runtime behaviour suggests that command execution logic may be dynamically constructed, resolved at runtime, or triggered only after the CAPTCHA and IPC event flow completes.
However, the binary contains extensive embedded network configuration, including multiple DNS-over-HTTPS (DoH) endpoints, certificate transparency reporting URLs, and public DNS infrastructure references from providers such as Cloudflare, Google, and CleanBrowsing. These entries are consistent with Chromium’s built-in networking, DNS resolution, and security telemetry mechanisms rather than explicit command-and-control infrastructure.
Unpacking the electron application
Static analysis was performed on the extracted app.asar contents to identify the application’s internal structure. The archive was successfully unpacked, revealing a JavaScript-based Electron application composed of multiple build artefacts, including several index.js files of varying sizes, alongside module formats such as CommonJS (.cjs), ES modules (.mjs), and TypeScript declaration files.
The presence of these artefacts indicates a bundled JavaScript build output typical of modern Electron applications using toolchains such as Webpack, Vite, or similar bundlers. In addition, an index.html file was present, confirming the existence of a renderer-side user interface layer consistent with standard Electron application architecture.
Figure 8: Findstr Output
Further inspection of the JavaScript bundle structure identified a large standalone script (winter.js) as the primary application artifact within the unpacked app.asar contents. This file was isolated based on size comparison against other JavaScript modules and library dependencies, with significantly larger file size indicating its role as the main bundled execution payload.
Static examination of winter.js revealed extensive obfuscation, including hex-encoded string literals, dynamically resolved function references, and control-flow manipulation techniques.
The resulting structure is not directly human-readable and does not expose conventional Electron entry patterns in a clear form, instead appearing as a packed JavaScript execution layer typical of bundled or protected Electron applications.
Due to extensive obfuscation within the primary bundle (winter.js), static analysis was unable to clearly reconstruct execution flow or application logic. The presence of encoded strings and dynamically resolved function mappings limited further code-level interpretation, leading to a transition towards controlled runtime observation to assess application behaviour during execution.
Chat_GPT.exe dynamic analysis
Dynamic analysis of the binary was performed, with system, process, and network activity monitored to assess runtime behaviour. Upon execution of Chat_GPT.exe, App.exe launches and presents a CAPTCHA challenge prior to allowing further interaction.
This behaviour is commonly associated with anti-automation or anti-analysis mechanisms intended to ensure execution occurs in a real user environment rather than an automated sandbox.
Figure 9: App.exe CAPTCHA
After the CAPTCHA is completed, App.exe creates a significant number of PowerShell.exe processes with the flags ‘-ExecutionPolicy Unrestricted -Command –‘. This shows that PowerShell is being started but the actual payload is being provided after launch, not directly in the command line.
Figure 10: App.exe Procmon Activity
Execution of the sample resulted in the creation of a Chromium-style application profile within %APPDATA%\Satoshi, including standard Electron storage artefacts such as cookies, local storage, cache directories, and application preference files.
The structure is consistent with a Chromium/Electron runtime environment and indicates that the application initialised a persistent user profile under the internal name “Satoshi” rather than presenting itself as a ChatGPT-branded application.
Figure 11: Dropped Files
Subsequent behavioural analysis suggests that the sample’s execution flow is heavily event-driven, with key functionality gated behind user interaction rather than initial process launch. This aligns with the absence of immediately visible payload activity during early execution stages, despite the presence of loader-like behaviour within the JavaScript bundle.
Figure 12: Event-Triggered Execution
Notably, the lack of observable inline command execution within the static winter.js file, combined with the use of runtime string resolution and obfuscation patterns, indicates that critical logic is likely constructed dynamically during execution. This significantly reduces the effectiveness of static keyword-based detection and explains why conventional searches for common indicators (such as exec, spawn, or direct PowerShell invocation strings) yielded no results.
Figure 13: Winter.js Obfuscation
During partial deobfuscation of the winter.js payload, multiple Node.js core and third-party modules were identified, including systeminformation, child_process, os, fs, zip-lib, http, and https.
The presence of these modules confirms that the application is not a passive script-based loader but instead operates as a fully capable Node/Electron execution environment with system interrogation, file system access, archive handling, process execution, and network communication capabilities. This significantly expands the observed threat surface beyond what static analysis of the obfuscated code initially suggested.
Figure 14: Capability Extraction From winter.js
The crash observed when executing the sample outside its intended Electron environment further supports the presence of environment-dependent logic. The application expects Electron-specific modules and IPC infrastructure, suggesting that parts of the payload chain are only initialised when the full runtime context is available.
Figure 15: Environment-bound Execution
Evidence of staged malware execution
From a behavioural perspective, this design is consistent with staged loaders that separate initial execution from secondary payload retrieval or decryption. In such cases, early execution primarily functions as an environment validator and trigger mechanism rather than directly delivering malicious functionality.
Due to the controlled analysis conditions and incomplete runtime emulation of the Electron environment, full Stage 2 execution was not observed. However, the available evidence strongly indicates that additional payload logic is conditionally executed following successful CAPTCHA completion and IPC event handling.
Key findings for defenders
Although the campaign relies heavily on convincing branding and social engineering, it presents several detection opportunities. Organisations should monitor for newly created executables launched from user-writable locations such as Downloads or Temp, particularly when filenames imitate trusted software.
Electron applications that repeatedly spawn powershell.exe or other scripting processes may warrant investigation, as may unexpected Chromium or Electron profile directories such as %APPDATA%\Satoshi. Security teams should also review installers where the filename, product metadata and code-signing publisher do not align. Monitoring or blocking access to newly registered domains impersonating legitimate software vendors can provide an additional layer of defence.
Conclusion: Why malvertising remains effective
This campaign illustrates how threat actors continue to exploit trusted brand recognition, in this case, OpenAI and ChatGPT, to distribute malware through paid search advertising. The use of malvertising as an initial access vector is particularly effective because it bypasses traditional phishing defences and targets users who are actively searching for legitimate software.
The technical characteristics of this campaign are notable. The use of an Electron-based loader with heavy JavaScript obfuscation, CAPTCHA gating, and event-driven payload execution demonstrates a deliberate effort to evade both automated sandboxes and static detection. The presence of separate payload paths for Windows and macOS users further suggests a broad targeting scope and a structured, modular approach to delivery.
Campaigns like this are a reminder that preventing every threat at the perimeter simply is not realistic. Malvertising in particular is difficult to defend against. Users are not behaving suspiciously when clicking a search result, and malicious infrastructure can be deployed and dismantled faster than blocklists can reliably keep pace.
What matters is what happens next: whether there is visibility of the telltale signs of compromise, such as unusual process behaviour, unexpected executables, and application directories that should not exist, and whether those signals can be acted on quickly. Without that visibility, infections like this can quietly carry out their objectives for days before anyone notices.
For many organisations, achieving that level of visibility consistently is the challenge. In some cases, a managed SOC capability can help bridge the gap between detection and response.
Continue reading
This campaign is another example of how attackers adapt their techniques to exploit trusted brands, evade detection and increase the likelihood of user interaction. While the delivery mechanism may change, the underlying themes remain consistent: social engineering, malware evasion and user trust.
For further analysis of modern threat techniques and defensive strategies, explore:
- Rhadamanthys PDF File Analysis – An in-depth look at how malware operators use PDF files and other techniques to bypass security controls and evade detection.
- Employee Phishing Testing – Learn how phishing simulations can help organisations identify risky behaviours and strengthen their human layer of defence.
- EDPB ChatGPT Taskforce Report – Explore the regulatory and privacy considerations surrounding ChatGPT and generative AI technologies.
Whether the challenge is malware delivery, phishing resilience or AI governance, understanding how threats evolve is the first step towards reducing risk.
Get in touch if you’d like to understand how the Evalian SOC team can help strengthen your cyber resilience.
