Your personal data has leaked due to suspected harmful activities.

by Administrator on Aug 25, 2026

OK

So this idiot actually sent this message through to the [email protected] email address, pretending thet they have hacked it.

Hi there!

I am a professional hacker and have successfully managed to hack your operating system.
Currently I have gained full access to your account.

In addition, I was secretly monitoring all your activities and watching you for several months.
The thing is your computer was infected with harmful spyware due to the fact that you had visited a website with porn content previously. â•­ á‘Ž â•®

Let me explain to you what that entails. Thanks to Trojan viruses, I can gain complete access to your computer or any other device that you own.
It means that I can see absolutely everything in your screen and switch on the camera as well as microphone at any point of time without your permission.
In addition, I can also access and see your confidential information as well as your emails and chat messages.

You may be wondering why your antivirus cannot detect my malicious software.
Let me break it down for you: I am using harmful software that is driver-based,
which refreshes its signatures on 4-hourly basis, hence your antivirus is unable to detect it presence.

I have made a video compilation, which shows on the left side the scenes of you happily masturbating,
while on the right side it demonstrates the video you were watching at that moment..áµ”.áµ”

All I need is just to share this video to all email addresses and messenger contacts of people you are in communication with on your device or PC.
Furthermore, I can also make public all your emails and chat history.

I believe you would definitely want to avoid this from happening.
Here is what you need to do - transfer the Bitcoin equivalent of 850 USD to my Bitcoin account
(that is rather a simple process, which you can check out online in case if you don't know how to do that).

Below is my bitcoin account information (Bitcoin wallet): bc1q4whppe29dw77rm4kv4pln0gqae4yjnxly0dny0hky6yhnafukzjsyrsqhk
Once the required amount is transferred to my account, I will proceed with deleting all those videos and disappear from your life once and for all.
Kindly ensure you complete the abovementioned transfer within 50 hours (2 days +).
I will receive a notification right after you open this email, hence the countdown will start.

Trust me, I am very careful, calculative and never make mistakes.
If I discover that you shared this message with others, I will straight away proceed with making your private videos public.

Good luck!

 

Comments (1) -

  • Berkshire Computers
    It is incredibly frustrating to see one of these land in an inbox after you've already tightened down your receive connectors.

    However, before diving into Exchange configurations, there is one critical thing to clarify first: this is a classic "sextortion" scam email.

    The sender has not hacked your OS, they are not recording you through your webcam, and they don't have a video compilation. It is a mass-phishing template sent out to millions of addresses using boilerplate text and a randomly generated (or reused) Bitcoin wallet.

    Why Did This Pass Your Relay Controls?
    If you previously locked down your Exchange Server receive connectors (e.g., stripping ms-Exch-SMTP-Accept-Any-Sender from your Default Frontend connector to stop unauthenticated internal domain spoofing), you might be wondering how this still got through.

    There are usually three common reasons these specific messages slip past relay restrictions:

    Header Spoofing vs. Envelope Spoofing (Display Name / From Header Trickery)
    Your Exchange server blocks unauthenticated connections where the Envelope MAIL FROM (P1) claims to be your internal domain.
    Scammers get around this by using a completely external domain in the envelope (MAIL FROM: [email protected]), which your server correctly accepts as legitimate inbound mail. However, inside the message headers, they set the Display From (P2 header) to match your internal address.
    Unless you have an explicit transport rule looking at the From: header field in the message body, Exchange will accept the mail because the envelope matched a valid external sender.
    External Relaying via an Open Upstream Gateway
    If inbound mail routes through a third-party hygiene service (like Mimecast, Proofpoint, or an ISP relay) before hitting Exchange, the connection to Exchange comes from a trusted IP.
    If the upstream filter didn't block the spoofed header or bogus sender, Exchange accepts it from the filter's IP without enforcing standard unauthenticated sender checks.
    Inbound Smart Host / Connector Scope
    If the sender delivered the mail using an external SMTP server that doesn't enforce SPF/DKIM/DMARC checks, and your Exchange server is exposed directly to port 25 without strict DMARC enforcement at the gateway, it will drop into the inbox.
    How to Check and Block These in Exchange
    To track down exactly how this bypassed your rules and block future attempts:

    1. Inspect the Message Headers
    Pull the full internet headers from the message and check two key lines:

    Return-Path: (This is the P1 Envelope sender. It's likely a random external address).
    From: (This is the P2 Display header shown in Outlook, likely spoofed to look like your domain or local user).
    2. Enforce SPF / DMARC or Transport Rules
    If the message used an external Return-Path but spoofed your domain in the From: line, standard relay controls won't catch it because it wasn't technically an unauthorized relay attempt-it was inbound mail.

    To block this pattern, you can set up a Mail Flow (Transport) Rule in Exchange:

    Condition: The sender is located 'Outside the organization' AND The sender's domain is 'yourdomain.com' (or The 'From' header contains 'yourdomain.com').
    Action: Reject the message with the explanation... OR Deliver the message to the hosted quarantine.
    3. Verify Anonymous Sender Permissions
    Double-check that the ms-Exch-SMTP-Accept-Any-Sender permission hasn't been re-granted on your public-facing receive connector (typically Default Frontend <ServerName>):

    Get-ReceiveConnector "YourServer\Default Frontend YourServer" | Get-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" | Where-Object {$_.ExtendedRights -like "*Accept-Any-Sender*"}
    If that permission is missing (as it should be for unauthenticated internet traffic), then this email almost certainly bypassed your checks via the P1 vs. P2 Header Spoofing method mentioned above rather than a traditional relay loophole.
    25 August 2026 - Reply

Add comment