ZipLine Campaign: A Sophisticated Phishing Attack Targeting US Companies

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.

Introduction

Check 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 Form

In 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 Campaign

Infection Chain

ZIP files

The 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.

LNK Analysis

The LNK file executes a PowerShell command that performs several coordinated actions:

• Locate the ZIP File
• Search for the original ZIP archive in several common folders:
  • Desktop
  • Downloads
  • Documents
  • Temp
  • ProgramData
  • Parent of current working dir
• Search for Embedded Script Marker
• After 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 Script
• The 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 Analysis

After 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.

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 Analysis

MixShell 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' <= c <= 'z':
            ch -= 32  # convert to uppercase
        v2 = ror4(v1, 13)
        v1 = (v2 + ch) & 0xFFFFFFFF
    return v1

def ror4(val, r_bits, max_bits=32):
    return ((val >> r_bits) | (val << (max_bits - r_bits))) & (2**max_bits - 1)

After all necessary API addresses are resolved, MixShell parses its configuration block, which is stored immediately after the shellcode’s code section.

Each configuration value is:

• Hex-encoded.
• XOR-encrypted with a key located at the end of the configuration data.

Earlier variants stored this configuration in plaintext, indicating that the developers are actively evolving the malware to evade detection.

The decoded configuration provides critical operational parameters:

STRING[] dns_domain_name
STRING[] communication_xor_key
STRING[] lure_file_name
STRING[] base64_string
STRING[] prepend_value
STRING[] append_value
STRING[][4] libraries
STRING[] current_version_reg_string
STRING[] product_id_string
STRING[] install_date_string
STRING[] volume
STRING[] verb
STRING[] payload_default_file_name
STRING[] pipe_process_name
STRING[] cleanup_command_line
STRING[] scheme
STRING[] http_domain
STRING[] config_xor_key

These values, together with the resolved API pointers, are centralized within MixShell’s runtime structure.

To ensure only one instance is active per host, MixShell creates a mutex whose name also doubles as its C2 identifier, which effectively fingerprints each infection to a specific machine. This name is generated as:

hex(100 + ProductId + InstallDate + SerialNumber)

DNS-First Command and Control

MixShell prefers to communicate with its C2 using DNS TXT record queries. The DNS subdomain format:

<prepend><hex(comm_key[0] ^ base64_str[0])><append>.<id_hex>.<time_hex>.<domain>

For example, with:

• prepend = ul
• XOR result = 44
• append = mg

The generated subdomain is ul44mg.

Each outbound request is a DNS TXT query. C2 responses follow the reverse process:

• Remove prepend/append markers.
• Convert the remaining data from string to hexadecimal bytes.
• Decrypt with the same XOR key used for outbound messages (which is part of the configuration).

If six consecutive DNS requests fail, MixShell falls back to HTTP while retaining the same encryption and data wrapping format for consistency.

Due to the 60-character maximum subdomain length enforced by MixShell, data sent to the C2 is chunked into smaller queries. The end of a message is marked by the append value in the subdomain, which allows the C2 to determine when transmission is complete. All outbound data is prefixed with the command ID before being encoded and transmitted.

Supported Commands

The implant supports a wide range of commands, from basic file operations to interactive reverse proxy shells:

Command ID	Command	Arguments	Description
“0”	ack	–	Adjust retry count.
“1”	Abort	–	Terminate and remove the program directory. Runs the command: “// /c rd /s /q %ProgramData%\ <dirname>”
“2”	Send lure name	–	Encrypt the lure file name with the XOR communication byte key and send it to C2.
“3”	Create Pipe	–	Internal IPC channel setup.
“4”	Run Command	command	Execute commands via pipe.
“5”	Read From Pipe	–	Send command output to C2.
“6”	Cleanup Pipes	–	Remove IPC pipes.
“7”	Write Files	URL	Download and save file to TEMP. If the file name is not in the given URL, it will be taken from the configuration.
“8”	Sockets method	port	Reverse proxy shell.
“9”	Close Socket	–	Close active connection.

Reverse Proxy (Command 8)

When Command 8 is invoked, MixShell follows this handshake sequence:

1. Connect to the C2 at the given port.
2. Receive a 4-byte key from the C2.
3. Send an initial message (type1=0, type2=0x33, "mix-socks-<hex_id>").
4. Receive confirmation (type2=0x33).
5. Open a second socket to the same port.
6. Receive a new 4-byte key.
7. Send 4096 zero bytes (type1=0, type2=0x53).
8. Receive a message (type2=0x77) indicating:
   • 00000001 → New IP/port
   • 00000003 → New domain
9. Connect to the new destination.
10. Relay traffic until type2 != 0x77.

This design allows MixShell to function as a flexible relay, enabling attackers to pivot to internal networks while seemingly blending in with legitimate network activity.

MixShell PowerShell variant

During our research, we identified a PowerShell-based variant of MixShell.

While its encryption routine (hex-encoded bytes + XOR) and overall infection flow (triggered after the same marker value in the ZIP file) are the same as in the shellcode version, this variant introduces several notable differences:

• Enhanced Anti-Debugging & Sandbox Evasion
  • Scans for analysis/debugging tools such as windbg, ida, wireshark, procmon, ollydbg, and immunity debugger.
  • Checks for sandbox-related named pipes: \\cuckoo, \\hgfs, \\vmci, \\vbox.
  • Searches BIOS and system identifiers for virtualization: qemu, virtual, vbox, vmware, xen.
  • Terminates if the physical memory is less than 4 GB.
  • Terminates if the CPU core count is below 4.
• Victim Identification
  • Uses the CRC32 hash of the ProductID as the victim ID.
• Alternate Persistence Mechanism
  • Establish persistence via a scheduled task.
  • Uses conhost.exe to execute the malware.
• Modified C2 Subdomain Structure
• <prepend><data_chunk><append>.<crc32(ProductID)><crc16(encoded_lurename)><modecode><time_hex>.<domain>
• Feature Differences
  • Omits the reverse proxy shell and file download capabilities.
  • In addition to the named pipes and cmd.exe, it can execute commands directly via PowerShell.

Infrastructure

The domains used by the threat actors to initiate email communication appear to be carefully selected for credibility and legitimacy. Many of these domains match the names of LLCs registered in U.S-based companies and in some cases, may have previously belonged to legitimate businesses.

However, a closer inspection of the websites hosted on these domains reveals that they are entirely fabricated. All the sites share identical content, layout, and structure, strongly suggesting they were cloned from a single template. Remarkably, the “About Us” pages across all domains display the same photograph of the supposed company founders – a stock image that, upon investigation, is a photo of White House butlers.

Figure 10 – White house butlers image found in “About Us” page.

Source: https://www.washingtonian.com/2014/06/26/meet-the-white-house-butlers-boss/

Figure 11 – Side-by-side comparison of two of the websites.

What stands out is that these domains were originally registered between 2015 and 2019, long before the ZipLine campaign began. By acquiring abandoned or dormant domains with legitimate business histories, the attackers significantly increased their chances of bypassing security filters and gaining the trust of targeted organizations. These aged domains benefit from long-standing DNS records, clean reputations, and business-sounding identities, making them highly effective for social engineering.

The first C2 domain we identified was tollcrm[.]com, which resolved to the name server IP address 172.210.58[.]69. Further analysis of this infrastructure revealed several additional domains associated with the same IP address, all linked to the same campaign and used for DNS tunneling-based C2 communication. These include:

• humcrm[.]com
• vnrsales[.]com
• atriocrm[.]com
• zappiercrm[.]com

Further examination of this server revealed what appears to be leftover or partially configured infrastructure, potentially representing components of a management interface. Among the artifacts was an empty database table, seemingly intended to store victim data, and a web-based panel containing functionality to execute commands, open reverse shells, or initiate file downloads using supplied URLs.

While we cannot confirm active use of this panel in the current campaign, the presence of these components provides a rare glimpse into the attacker’s potential tooling and backend environment.

Victimology

Our analysis of the ZipLine phishing campaign reveals a diverse set of dozens of targeted organizations across multiple sectors, varying company sizes, and several geolocations, but with a clear emphasis on US-based entities. The majority of the targeted companies are in industrial manufacturing, including machinery, metalwork, component production, and engineered systems. Other affected industries include hardware & semiconductors, consumer goods & services, and biotech & pharmaceuticals. This distribution suggests that the attacker seeks entry points across wealthy operational and supply chain-critical industries instead of focusing on a specific vertical.

The inclusion of consumer electronics, aerospace, and energy companies, together with more traditional industrial targets, indicates the actors may be pursuing organizations with valuable proprietary data, strong vendor networks, or exploitable infrastructure.

Figure 13 – Targeted companies by industry.

The campaign does not discriminate based solely on organizational size. While Enterprise-level companies make up the majority of identified targets, a significant portion of Small and Medium Businesses (SMBs) were also affected. Larger targets offer potential high-value opportunities, while smaller organizations present softer entry points with fewer security controls.

Figure 14 – Targeted companies by size.

The long-term engagement with the victim (multi-week conversations) suggests that the attacker is willing to invest time cultivating the relationship regardless of company size, possibly tailoring their efforts based on perceived value or ease of compromise. More than 80% of the identified targets in this campaign are based in the United States, underscoring a clear geographic concentration, while also companies in Singapore, Japan and Switzerland were targeted. Overall, the engagement patterns observed were U.S-centric regarding infrastructure, communication style, and initial access points.

Attribution

The campaign’s targets come from a wide range of sectors and the underlying motivations, aside from financial gain, remain unclear.

However, during our infrastructure analysis, we identified overlapping certificates involving the IP address 172.210.58[.]69. This IP shares an SSL/TLS certificate with five other IP addresses. One of these, 162.33.179[.]82, hosts the domain mainstomp[.]cloud, which Zscaler previously reported in relation to the TransferLoader campaign. Subsequently, Proofpoint attributed this infrastructure to a cybercriminal cluster they track as “UNK_GreenSec.”

While this overlap does not constitute definitive attribution, it does suggest a potential connection to financially motivated threat actors who may be reusing infrastructure or operating within the same ecosystem.

Conclusion

In this report, we analyzed ZipLine, a financially motivated phishing campaign that reflects the evolving tactics of advanced phishing campaigns. In a unique reversal of the typical phishing pipeline, the threat actors force the victims to make the initial contact. A business’s “Contact Us” form submission enables them to seamlessly integrate into legitimate business workflows, thereby weaponizing trust, patience, and legitimate services to evade suspicion. By using multi-stage payloads, in-memory execution, and DNS-based C2 channels, the campaign achieves both stealth and adaptability across its infection chain.

For defenders, ZipLine reminds them that inbound communication vectors, including seemingly benign channels like corporate web forms, can be exploited as initial access points. Traditional detection methods focused on single-message analysis are insufficient to protect against this threat.

How Check Point Protects Against ZipLine-Like Attacks

Check Point Harmony Email & Collaboration provides proactive defense against advanced phishing and social-engineering campaigns like ZipLine. By analyzing communication context, sender reputation, and behavioral indicators, rather than relying on single-message analysis, Harmony Email and Collaboration detects attacks that unfold gradually over days or weeks. Its AI-driven phishing prevention, threat emulation for malicious attachments and ZIP archives, and real-time URL protection block the delivery of weaponized payloads before they reach users.

Harmony Email and Collaboration also prevents account takeover and business email compromise through behavioral analysis, while data loss prevention safeguards sensitive IP and supply chain data from exfiltration. Together, these layers ensure organizations remain protected even when attackers exploit trusted channels such as corporate web forms or extended business correspondence.

IOCs

Hashes:

• e69d8b96b106816cb732190bc6f8c2693aecb6056b8f245e2c15841fcb48ff94
• d39e177261ce9a354b4712f820ada3ee8cd84a277f173ecfbd1bf6b100ddb713
• f531bec8ad2d6fddef89e652818908509b7075834a083729cc84eef16c6957d2
• 2c7bc0ebbbfa282fc3ed3598348d361914fecfea027712f47c4f6cfcc705690f
• 71dec9789fef835975a209f6bc1a736c4f591e5eeab20bdff63809553085b192
• 83b27e52c420b6132f8034e7a0fd9943b1f4af3bdb06cdbb873c80360e1e5419
• f5a80b08d46b947ca42ac8dbd0094772aa3111f020a4d72cb2edc4a6c9c37926
• 15d024631277f72df40427b8c50e354b340fac38b468f34826cc613b4650e74c
• 155bccbd11066ce5bf117537d140b920f9b98eaa0d3b86bdc8a04ac702a7a1ef
• 4dcff9a3a71633d89a887539e5d7a3dd6cc239761e9a42f64f42c5c4209d2829
• d6e1e4cc89c01d5c944ac83b85efa27775103b82fece5a6f83be45e862a4b61e
• 81c1a8e624306c8a66a44bfe341ec70c6e3a3c9e70ac15c7876fcbbe364d01cd
• 36b065f19f1ac2642c041002bc3e28326bec0aa08d288ca8a2d5c0d7a82b56e6
• f44107475d3869253f393dbcb862293bf58624c6e8e3f106102cf6043d68b0af

Domains & IP addresses:

• lvprocurement[.]com
• kprocurement[.]com
• lamyconsulting[.]com
• trilineconsulting[.]com
• hancockconsulting[.]com
• caultonconsulting[.]com
• chipmanconsulting[.]com
• kgmstrategy[.]com
• crosleyconsulting[.]com
• humcrm[.]com
• tollcrm[.]com
• atriocrm[.]com
• vnrsales[.]com
• zappiercrm[.]com
• crmforretailers[.]com
• 172.210.58[.]69
• 212.83.190[.]143
• 5.180.221[.]108
• 185.180.221[.]108

• hxxps://signstream-docs-de3fa399b173[.]herokuapp[.]com
• hxxps://collab-sign-8e36fa762841[.]herokuapp[.]com
• hxxps://viewshare-4a47630892e1[.]herokuapp[.]com
• hxxps://legal-sign-8ec8b9f1edb2[.]herokuapp[.]com
• hxxps://docsign-hub-3295a03470c3[.]herokuapp[.]com
• hxxps://signflow-e15eda21396d[.]herokuapp[.]com
• hxxps://webmailapp-0e6cff4089a4[.]herokuapp[.]com
• hxxps://webmailapp-0e6cff4089a4[.]herokuapp[.]com
• hxxps://clear-sign-e69444a8e4ea[.]herokuapp[.]com
• hxxps://signhub-view-09a16562134b[.]herokuapp[.]com
• hxxps://mail-serve-9a5d4f13e3a7[.]herokuapp[.]com
• hxxps://mail-serve-9a5d4f13e3a7[.]herokuapp[.]com
• hxxps[:]//docvault-share-665d141177ca[.]herokuapp[.]com
• hxxps://signlink-portal-37c581992418[.]herokuapp[.]com
• viewshare-4a47630892e1[.]herokuapp[.]com
• signforge-a61a5975a04b[.]herokuapp[.]com
• sharespace-link-360b265f3942[.]herokuapp[.]com
• hxxps://signtrack-docs-6a96b334b140[.]herokuapp[.]com
• signcentral-vault-33ce0aff08dc[.]herokuapp[.]com
• signcentral-7df32454744c[.]herokuapp[.]com
• hxxps://john-deer-apple-0c6f34d9c276[.]herokuapp[.]com