ZipLine Phishing Campaign Targets U.S. Manufacturing - CPR - Check Point Research

ZIPLINE CAMPAIGN: A SOPHISTICATED PHISHING ATTACK TARGETING US COMPANIES August 26, 2025 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 Figure 5 – ZipLine 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. Figure 6 – NDA document used as a lure file. 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. 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 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. Figure 8 – MixShell’s configuration. 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: Connect to the C2 at the given port. Receive a 4-byte key from the C2. Send an initial message (type1=0, type2=0x33, "mix-socks-<hex_id>"). Receive confirmation (type2=0x33). Open a second socket to the same port. Receive a new 4-byte key. Send 4096 zero bytes (type1=0, type2=0x53). Receive a message (type2=0x77) indicating: 00000001 → New IP/port 00000003 → New domain Connect to the new destination. 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. Figure 9 – Reverse Proxy initial message. 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. Figure 12 – Attacker control panel. 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 GO UP BACK TO ALL POSTS POPULAR POSTS ARTIFICIAL INTELLIGENCE CHATGPT CHECK POINT RESEARCH PUBLICATIONS OPWNAI : Cybercriminals Starting to Use ChatGPT CHECK POINT RESEARCH PUBLICATIONS THREAT RESEARCH Hacking Fortnite Accounts ARTIFICIAL INTELLIGENCE CHATGPT CHECK POINT RESEARCH PUBLICATIONS OpwnAI: AI That Can Save the Day or HACK it Away BLOGS AND PUBLICATIONS CHECK POINT RESEARCH PUBLICATIONS August 11, 2017 “THE NEXT WANNACRY” VULNERABILITY IS HERE CHECK POINT RESEARCH PUBLICATIONS March 12, 2026 “HANDALA HACK” – UNVEILING GROUP’S MODUS OPERANDI CHECK POINT RESEARCH PUBLICATIONS GLOBAL CYBER ATTACK REPORTS THREAT RESEARCH February 17, 2020 “THE TURKISH RAT” EVOLVED ADWIND IN A MASSIVE ONGOING PHISHING CAMPAIGN CHECK POINT RESEARCH PUBLICATIONS August 11, 2017 “THE NEXT WANNACRY” VULNERABILITY IS HERE CHECK POINT RESEARCH PUBLICATIONS March 12, 2026 “HANDALA HACK” – UNVEILING GROUP’S MODUS OPERANDI CHECK POINT RESEARCH PUBLICATIONS GLOBAL CYBER ATTACK REPORTS THREAT RESEARCH February 17, 2020 “THE TURKISH RAT” EVOLVED ADWIND IN A MASSIVE ONGOING PHISHING CAMPAIGN CHECK POINT RESEARCH PUBLICATIONS August 11, 2017 “THE NEXT WANNACRY” VULNERABILITY IS HERE 123 This website uses cookies in order to optimize your user experience as well as for advertising and analytics.  For further information, please read our Privacy Policy and ourCookie Notice. 404 Not Found nginx When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer. More information Allow All Manage Consent Preferences Functional Cookies Functional Cookies These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly. Strictly Necessary Cookies Always Active These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information. Performance Cookies Performance Cookies These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance. Targeting Cookies Targeting Cookies These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising. Performance Cookies Clear checkbox label label Apply Cancel Consent Leg.Interest checkbox label label checkbox label label checkbox label label Reject All Confirm My Choices