Key findings:Check Point Research has been monitoring a sophisticated social-engineering campaign targeting supply chain–critical manufacturing companies, where attackers leverage legitimate-looking business interactions to stealthily deliver a custom malware implant.The attacker initiates the communication via targeted company’s public “Contact Us” form, making the overture appear legitimate. The typical phishing flow is reversed as the victim then initiates the email correspondence.The attackers maintain credible, business-oriented email conversations with the victim for weeks before delivering a malicious ZIP payload. One of the business themes that the attackers started using in the recent social engineering wave is “AI transformation” pretext, framed as an internal AI Impact Assessment.In many cases, the attacker uses domains that match the names of LLCs registered U.S.-based companies, and in some cases, may have previously belonged to legitimate businesses. The attacker maintains similar template websites to all those companies, which hint at a well-planned and streamlined campaign on a large scale.The payload is delivered as a ZIP archive that includes a PowerShell script embedded within the archive’s binary data, positioned after a specific marker string. A loader PowerShell later extracts the script and executes it in memory.A custom in-memory implant called “MixShell” is a stealthy shellcode payload using DNS TXT tunneling with HTTP fallback for the C2. MixShell supports file operations, reverse proxying, command execution, and pipe-based interactive sessions.IntroductionCheck Point Research (CPR) has been closely monitoring the activity of a highly persistent and sophisticated threat actor who leverages social engineering tactics to gain the trust of targeted U.S.-based organizations. While analyzing the phishing lures used by the actors, we repeatedly noticed an intriguing pattern: in every case, it was the victim who initiated the email exchange that ultimately led to infection. This unusual detail prompted a deeper investigation, which revealed an elaborate and highly resourceful phishing campaign.This campaign, which we named ZipLine, the attackers diverge from traditional phishing methods by initiating contact through the victim’s own “Contact Us” web form. The targeted company naturally responds via email to the form submission, lending the interaction an immediate sense of legitimacy. This reversal of the typical phishing pathway is followed by a carefully orchestrated email conversation, often lasting two weeks, between the attackers and the unsuspecting victim, in which the attackers pose as a potential business partner and request the signing of a Non-Disclosure Agreement (NDA).Once trust is established, the attackers deliver a ZIP archive hosted on a trusted platform. Embedded within the archive is a malicious .lnk file that triggers a PowerShell-based loader, ultimately deploying MixShell, a custom in-memory implant featuring a DNS based command and control (C2) and enhanced persistence mechanisms.In this report, we examine the structure of the ZipLine campaign, explore the tactics that make it particularly deceptive, and provide a technical deep dive into MixShell.Initial Access via Contact FormIn all the incidents we analyzed, the attacker initiates contact through a third party channel, most likely a “Contact Us” form found on the target company’s website. The targeted company naturally responds to this overture via email, reversing the usual attacker-initiated communication pattern, lowering suspicion, and avoiding reputation-based detection mechanisms.In some cases, the actor exchanges emails with the victim for up to two weeks, discussing scheduling a meeting before ultimately sending a malicious ZIP file. This extended interaction helps the attackers bypass email protection mechanisms and build additional trust with the victim organization.Figure 1 – The attackers’ message submitted on the company’s “Contact Us” form.After receiving the form submission, the company typically replies to confirm receipt and may ask follow-up questions or offer to schedule a call. The attacker maintains a convincing dialogue, building rapport with the victim over time.Figure 2 – Social engineering flow of the ZipLine campaign.In all observed cases, the malicious link sent by the attackers pointed to a subdomain of herokuapp.com. Heroku is a legitimate Platform-as-a-Service (PaaS) providing compute and storage infrastructure for hosting web applications. In this campaign, the threat actors abuse the platform to host and deliver the weaponized ZIP archive. The use of a trusted and commonly used domain may help the attackers reduce victims’ suspicions.Check Point Research notified Heroku of the malicious content that the attackers hosted on their platform.Figure 3 – Delivery of the malicious NDA ZIP file.While finalizing this publication, we observed a new wave of phishing emails associated with the ZipLine campaign, centered around an AI transformation pretext. In this variation, the attacker claims to be working with the target’s organization to help implement AI-driven operational changes aimed at reducing costs and improving efficiency.The email is positioned as an internal initiative and framed as an “AI Impact Assessment”, asking the recipient to review a short questionnaire about how artificial intelligence might affect their team’s workflows. To increase legitimacy and urgency, the attacker explicitly states that the company’s leadership requested the recipient’s personal input, implying that their opinion will influence upcoming decisions.At this stage, the payload used in this AI-themed variant has not yet been observed. However, based on the attacker’s continued use of previously established infrastructure, we assess with high confidence that it is likely to follow a similar delivery model as seen in earlier stages of the ZipLine campaign—potentially involving staged delivery, a weaponized ZIP archive, and in-memory execution of a backdoor such as MixShell.Figure 4 – AI-Themed Phishing Email Used in ZipLine CampaignInfection ChainFigure 5 – ZipLine infection chain.ZIP filesThe archive contains three files: Legitimate PDF and DOCX files used as lures, and a malicious LNK file responsible for initiating the execution chain. The ZIP archive itself contains a PowerShell script embedded directly within its binary content, which is later extracted and executed in memory by the .lnk-initiated payload.Interestingly, not all the ZIP files observed in this campaign were malicious. In several cases, the archive contained only harmless documents, with no embedded scripts or active payloads. This suggests that the malicious content may be dynamically served from the Herokuapp-hosted delivery domain, with the payload customized in real time based on factors such as the recipient’s IP address, user-agent, or other contextual indicators.Figure 6 – NDA document used as a lure file.LNK AnalysisThe LNK file executes a PowerShell command that performs several coordinated actions:Locate the ZIP FileSearch for the original ZIP archive in several common folders:DesktopDownloadsDocumentsTempProgramDataParent of current working dirSearch for Embedded Script MarkerAfter the ZIP file is located, the script scans the file for a hardcoded marker string (xFIQCV). This marker is used to identify the start of the embedded PowerShell payload within the ZIP’s binary data.Extract and Execute Embedded ScriptThe PowerShell script:Extracts the embedded PowerShell payload from the ZIP.Copies the ZIP archive to the ProgramData folder and extracts it there.Opens the .docx file to maintain the appearance of legitimacy.Performs an AMSI (Antimalware Scan Interface) bypass. It sets System.Management.Automation.AmsiUtils.amsiInitFailed = $true, which tricks AMSI into thinking it failed to initialize.Executes the next-stage PowerShell payload after it removes all “#” characters.ZIP PowerShell AnalysisAfter the embedded PowerShell script is extracted and executed, it first substitutes placeholder values with the actual script file path and the .lnk shortcut path.Next, the script establishes persistence using the TypeLib hijacking technique. The TypeLib registry hive, which stores metadata about COM objects and their associated CLSIDs, is modified to target the CLSID {EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}, an identifier tied to Microsoft Web Browser components. The script assigns this CLSID to point to a local file named Udate_Srv.sct.This .sct file is created by the PowerShell script and populated with a malicious XML scriptlet. The scriptlet content, originally Base64-encoded, is decoded and written to disk with the script: moniker. This COM-specific mechanism instructs Windows to interpret and execute the script content when the associated COM object is invoked.As a result, the malicious code executes automatically whenever the hijacked COM object is accessed, by launching Internet Explorer, or by another application embedding IE components, or even by a system process that indirectly calls into that COM functionality. Notably, Windows Explorer (explorer.exe) triggers this COM object during normal operation. This means the payload will execute on every system restart without any manual user action, helping it to maintain long-term persistence.The injected scriptlet contains JScript code that checks if the malware’s .lnk shortcut (which launches the primary payload) is already running. It queries if a process contains “cmd.exe” and if the command line contains the “/K” switch. If not found, the script assumes that the payload is not active. Therefore, it creates a shell and runs the command cmd.exe /K set X=1&{cmd} while {cmd} is the .lnk file.The malware’s .lnk file will be re-executed automatically whenever the hijacked COM object is triggered, even if the payload was terminated. This ensures persistence and reactivation without any user action.Figure 7 – The injected scriptlet.After establishing persistence, the PowerShell script checks the system architecture (32-bit or 64-bit) and selects the corresponding shellcode. This shellcode is stored in the script as a Base64-encoded blob encrypted via XOR with a hardcoded key.The script then uses reflection and the System.Reflection.Emit API to dynamically construct custom .NET delegate types at runtime. This enables it to resolve module handles, locate function pointers via GetProcAddress, and bind these unmanaged functions directly to delegates. All of this takes place in the memory, leaving minimal forensic traces on the disk. Using this approach, the script allocates executable memory with VirtualAlloc, copies the decrypted shellcode and invokes it directly, enabling it to execute the payload without dropping any additional files to disk.MixShell AnalysisMixShell begins execution by dynamically locating required Windows API functions and storing their addresses in the shellcode’s main runtime structure. Instead of embedding plain API names, it uses a custom ROR4 hashing algorithm to identify them.The hashing routine works as follows:def api_hash(s): v1 = 0 for c in s: ch = ord(c) if 'a' r_bits) | (val