Detecting a storm of ZipLine attacks with KQL
A technical breakdown of the ZipLine initial access campaign linked to Qilin ransomware, and how to detect the HTA delivery chain in Microsoft Defender XDR.

Background

Since May 2026, CERT Austria has been tracking an active phishing campaign targeting organisations across the DACH region. The campaign, referred to as ZipLine, is linked to the Qilin ransomware-as-a-service operation and has been observed hitting organisations across multiple sectors including manufacturing, healthcare, and professional services.

Emails arrive with subjects like Jobangebot: Country Manager or Dienstangebot, impersonating legitimate recruiting activity. The sender domains are either freshly registered or compromised, keeping reputation-based filtering largely blind at the time of delivery.

CERT


Delivery

The campaign uses two delivery methods in parallel, which is what makes it harder to block at the perimeter.

Method 1: ZIP attachment

A ZIP file is attached directly to the mail. The archive contains two or three files that look legitimate — a PDF, a DOCX — alongside a hidden .hta file named to blend in, for example Dienstangebot_N_Name_19-05-26.docx.hta. Windows hides known file extensions by default, so most users see Dienstangebot_N_Name_19-05-26.docx and open it without hesitation.

Method 2: Download link in mail body

Instead of attaching the ZIP, some variants include a direct download link in the mail body pointing to a Heroku-hosted URL, for example:

https://some-company-a15r-851969a744f2.herokuapp.com/Dienstangebot_Name_N_19-05-26.zip

The Heroku subdomain is freshly created per campaign wave and taken offline within hours of delivery, which is why sandbox detonation after the fact returns nothing.

ZipLine

The .hta file carries no malware signature, as it executes using mshta.exe, a signed Microsoft binary that Windows ships with.


Detection

The most reliable signal is a .hta file written to disk where FileOriginReferrerUrl points to a ZIP archive or a web URL. This field survives the extraction step — Windows traces the origin of the extracted file back to the container, whether that container is a local ZIP or a remote download.

DeviceFileEvents
| extend OriginalFile = extract(@"[^\\]+$", 0, FileOriginReferrerUrl)
| where isnotempty(FileOriginReferrerUrl)
| where FileName matches regex @"(?i)\.(docx|xlsx|pdf)\.hta$"
| extend Source_Type = case(FileOriginReferrerUrl startswith "https://", "Web", "File")
| join kind=inner (DeviceEvents) on $left.InitiatingProcessUniqueId == $right.InitiatingProcessUniqueId
| project TimeGenerated, AccountUpn = strcat(InitiatingProcessAccountUpn),
          Device = strcat(DeviceName), FileName, OriginalFile,
          FileOriginReferrerUrl, Source_Type, FolderPath, ActionType, SHA2561

The FileName matches regex condition targets the double-extension pattern specifically. A file named document.hta does not match; document.docx.hta does. This cuts false positives significantly compared to filtering on extension alone.

Source_Type tells you which delivery method hit: Web means the ZIP came via a direct download link, File means it came as a mail attachment and was extracted locally.


Indicators of Compromise

Delivery domains (from CERT Austria report): see https://www.cert.at/de/aktuelles/2026/5/zipline-qilin-raas-update Heroku staging infrastructure: herokuapp.com
Filename pattern: <name>_<initials>_DD-MM-YY.docx.hta