Category Archives: email

Collection #1 Data Breach Exposes Nearly 733 Million Records, Highlighting Need for Multifactor Authentication

The theft of nearly 733 million unique email messages and 21 million passwords underscores the urgent need for multifactor authentication in the enterprise.

First discovered by security researcher Troy Hunt, records from the data breach were published to a hacker forum as well as the cloud-based service MEGA, though they have since been removed.

Dubbed Collection #1, the perpetrators behind the theft remain unknown, but the volume of 12,000 files suggests that it may have involved multiple incidents and actors. Cleaned-up versions of the files have been loaded into Have I Been Pwned, which users can leverage to check whether their data was compromised in the breach.

Why Collection #1 Data Is Particularly Dangerous

While any data breach of this magnitude would raise concerns, the files included in Collection #1 include login credentials that have been dehashed. In other words, the threat actors who stole the information were able to convert it into plain text.

This could make it a lot easier for attackers to use those credentials to break into various email servers and other online systems. By using bots, for instance, threat actors could launch credential-stuffing attacks to access multiple accounts with the same stolen password, as Forbes pointed out.

Use Multifactor Authentication Where It Counts

The Collection #1 breach serves as a reminder that a password alone is not enough to protect data from theft or misuse. When emails, login credentials or other files belonging to a business or government organization are compromised, the risk of financial or reputational damage is even greater.

Obviously, the sensitivity of this data necessitates stronger protection for individual workstations and business applications, but IT professionals should also consider the security of the mainframes that keep so many operations and processes running within the enterprise. Multifactor authentication adds layers of defense that credential-stealing threat actors will need to penetrate to access the mainframes, devices and IT infrastructure that holds valuable enterprise data.

The post Collection #1 Data Breach Exposes Nearly 733 Million Records, Highlighting Need for Multifactor Authentication appeared first on Security Intelligence.

Nearly 800 Million Email Addresses Exposed in “Collection #1” Data Breach

A data breach known as “Collection #1” exposed approximately 800 million email addresses as well as tens of millions of passwords. In the beginning of January, multiple people reached out to Australian web security expert Troy Hunt about a sizable collection of files hosted on cloud service MEGA. This collection, which is no longer available […]… Read More

The post Nearly 800 Million Email Addresses Exposed in “Collection #1” Data Breach appeared first on The State of Security.

Del Rio City Hall Disables Internet Connection for All Departments after Ransomware Attack

Officials in the City of Del Rio have disabled the internet connection for all departments at City Hall following a ransomware attack. The City of Del Rio, which is located 152 miles west of San Antonio in Val Verde County, Texas, posted a statement to its website disclosing the attack. Its statement mainly offers insight […]… Read More

The post Del Rio City Hall Disables Internet Connection for All Departments after Ransomware Attack appeared first on The State of Security.

Your trust, our signature

Written and researched by Mark Bregman and Rindert Kramer

Sending signed phishing emails

Every organisation, whatever its size, will encounter phishing emails sooner or later. While the number of phishing attacks is increasing every day, the way in which phishing is used within a cyber-attack has not changed: an attacker comes up with a scenario which looks credible enough to persuade the target to perform a certain action like opening an attachment or clicking on a link in the email. To avoid such attacks the IT or security team will tell users to check for certain things to avoid falling for these phishing emails. One of the recommendations is to check if the email is digitally signed with a valid certificate. However, in this blog, we present an attack that abuses this recommendation to regain the recipient’s trust in the sender.

Traditional phishing

Countless organizations have fallen victim to traditional phishing attacks where the attacker tries to obtain credentials or to infect a computer within the target network. Phishing is a safe way to obtain such footholds for an attacker. The attacker can just send the emails, sit back and wait for the targets to start clicking.

At Fox-IT we receive lots of requests to run simulated phishing attacks; so our team sends out hundreds of thousands of carefully crafted emails every year to clients to simulate phishing campaigns. Whether it’s a blanket campaign against the entire staff or a spear phishing one against targeted individuals, the big issue with phishing stays the same; we need to persuade one person to follow our instructions. We are looking for the weakest link. Sometimes that is easy, sometimes not so much. But an attacker has all the time in the world. If there is no success today, then maybe tomorrow, or the day after…
To create security awareness among employees, IT or the security team will tell their users to take a close look at a wide variety of things upon receiving emails. Some say you have to check for spelling mistakes, others say you have to be careful when you receive an email that tries to force you to do something (“Change your password immediately, or you will lose your files”), or when something is promised (“Please fill in this survey and enter the raffle to win a new iPhone”).

SPF records

Some will tell their users to check the domain that sent the email. But others might argue that anyone can send an email from an arbitrary domain; what’s known as ‘email spoofing’.

Wikipedia defines this as:

Email spoofing is the creation of email messages with a forged sender address. Because the core email protocols do not have any mechanism for authentication, it is common for spam and phishing emails to use such spoofing to mislead the recipient about the origin of the message.

— Wikipedia https://en.wikipedia.org/wiki/Email_spoofing

This means that an email originating from the domain “ fox-it.com ”, may not have been sent by an employee of Fox-IT. This can be mitigated by implementing Sender Policy Framework (SPF) records. In an SPF record you specify which email servers are allowed to send emails on behalf of your domain. If an email originating from the domain “ fox-it.com ” was not sent by the email server specified in the SPF record, the email message can be flagged as SPAM. By using SPF records you know that the email was sent by an authorized email server, SPF records however, do not disclose the authenticity of the sender. If a company has configured their SMTP server as an open relay server, users can send mail on another user’s behalf which will pass the SPF record check on the receivers end. There are other measures that can be used to identify legitimate mail servers to reduce phishing attacks, such as DKIM and DMARC, however, these are beyond the scope of this blogpost.

What is a digital signature?

To tackle the problem of email spoofing some organizations sign their emails with a digital signature. This can be added to an email to give the recipient the ability to validate the sender as well as the integrity of the email message.
For now we’ll focus on the aspect of validating the sender rather than the message integrity aspect. When the email client receives a signed email, it will check the attached certificate to see who the subject of the certificate is (i.e.: “john.doe@fox-it.com “). The client will check if this matches the originating email-address. To verify the authenticity of the digital signature, the email client will also check if the certificate is issued (signed) by a reputable Certificate Authority (CA). If the certificate is signed by a trusted Certificate Authority, the receiving email client will tell the recipient that the email is signed using a valid certificate. Most email clients will in this case show a green checkmark or a red rosette, like the one in the image below.

6oQvhoK

By default there is a set of trusted Certificate Authorities in the Windows certificate store. With digital certificates, everything is based on trusting those third parties, the Certificate Authorities. So we trust that the Certificate Authorities in our Windows certificate store give out certificates only after verifying that the certificate subject (i.e.: “john@fox-it.com “) is who they say they are. If we receive a signed email with a certificate which is verified by one of the Certificate Authorities we trust, our systems will tell us that the origin of the email is trusted and validated.
Obviously the opposite is also true. If you receive a signed email and the attached certificate is not signed by a Certificate Authority which is in the Windows certificate store, then the signature will be considered invalid. It is possible to attach a self-signed certificate to an email; in which case the email will be signed, but the receiving email client won’t be able to validate the authenticity of the received certificate and therefore will show a warning message to the recipient.

OxmuNkt

Common misconception regarding email signing

Some IT teams are pushing email signing as the Holy Grail to avoid being caught by a phishing email, because it verifies the sender. And if the sender is verified, we have nothing to worry about.

Unfortunately, the green checkmark or the red rosette which accompanies a validated email signature seems to stimulate the same behavior as we’ve seen with the green padlock accompanying HTTPS websites. Users see the green padlock in their browser and think that the website is absolutely safe. Similarly, they see the green checkmark or the red rosette and make the assumption that everything is safe: it’s a signed email with a valid certificate, the sender is verified, which means everything must be OK and that the email can’t be a phishing attack.

This may be true, if alice@fox-it.com sends you a signed email with a valid certificate: the sender really is Alice from Fox-IT, provided that the private key of the certificate is not compromised. But, if alice@fox-it.cm (notice the ‘.cm’ instead of ‘.com’) sends you a signed email with a valid certificate, that person can still be anyone. As long as that person has control over the domain ‘fox-it.cm’, they will be able to send signed emails from that domain. Because many users are told that the green checkmark or the red rosette protects against phishing, they may be caught off guard if they receive an email containing a valid certificate.

Sending signed phishing emails

At Fox-IT we’re always trying to innovate, meaning in this case that we’re looking for ways to make the phishing emails in our simulations more appealing to our client’s employees. Adding a valid certificate makes them look genuine and creates a sense of trust. So when running phishing simulations we use virtual private servers to do the job. For each simulation we setup a fresh server with the required configuration in order to deliver the best possible phishing email. To send out the emails, we’ve developed a Python script into which we can feed a template, some variables and a target list. Recently we’ve updated the script to include the ability to sign our phishing emails. This results in very convincing phishing emails. For example, in Microsoft Office Outlook one of our phishing emails would look like this:

8A9oUnj

This is not limited to Office Outlook only, it is working in other mail clients as well, such as Lotus Notes. Although Lotus Notes doesn’t have a red rosette to show the user that an email is digitally signed, there are some indicators which are present when reading a signed email. As you can see below, the digital signature does still add to the legitimate look of the phishing emails:

5floNBj

Going the extra mile

The user has now received a phishing mail that was signed with a legitimate certificate. To make it look even more genuine, we can mention the certificate in the phishing mail. Since the Dutch government has a webpage1 with information about the use of electronic signatures in email, we can write a paragraph that looks something like the the one in the image below.

gov

Sign the email

The following (Python) code snippet shows the main signing functionality:

# Import the necessary classes from M2Crypto library
from M2Crypto import bio, rand, smime

# Make a MemoryBuffer of the message.
buf = makebuf(msg_str)

# Seed the PRNG.
Rand.load_file('randpool.dat', -1)

# Instantiate an SMIME object; set it up; sign the buffer.
s = SMIME.SMIME()
s.load_key('key.pem', 'cert.pem')
p7 = s.sign(buf, SMIME.PKCS7_DETACHED)

# Recreate buf.
buf = makebuf(msg_str)

# Output p7 in mail-friendly format.
out = BIO.MemoryBuffer()
out.write('From: %s\n' % sender)
out.write('To: %s\n' % target)
out.write('Subject: %s\n' % subject)

s.write(out, p7, buf)
msg = out.read()

# Save the PRNG's state.
Rand.save_file('randpool.dat')

This code originates from the Python M2Crypto documentation2

For the above code to work, the following files must be in the same directory as the Python script:
* The public certificate saved as cert.pem
* The private key saved as key.pem

There are many Certificate Authorities that allow you to obtain a certificate online. Some even allow you to request a certificate for your email address for free. A quick google query for “free email certificate” should give you enough results to start requesting your own certificate. If you have access to an inbox you’re good to go.
To get an idea of how the above code snippet can be included in a standalone script, we’d like to refer to Fox-IT’s Github page where we’ve uploaded an example script which takes the most basic email parameters (‘from’, ‘to’, ‘subject’ and ‘body’). Don’t forget to place the required certificate and corresponding key file in the same directory with the Python script if you start playing around with the example script. Link to project on GitHub: https://github.com/fox-it/signed-phishing-email

Mitigation

There are some mitigations that can make this type of attack harder to perform for an attacker. We’d like to give you some tips to help protect your organisation.

Prevent domain squatting

The first mitigation is to register domains that look like your own domain. An attacker that sends a phishing mail from a domain name that is similar to your own domain name can trick users into executing malware or giving away their credentials more easily. This type of attack is called domain squatting, which can result in examples like fox-it.cm instead of fox-it.com . There are generators that can help you with that, such as: https://github.com/elceef/dnstwist

Restrict Enhanced Key Usages

Another mitigation has a more technical approach. For that we need to look into how certificates are used. Let’s say we have an internal Public Key Infrastructure (PKI) with the following components:
* Root CA
* Subordinate CA

The root CA is an important server in an organisation for maintaining integrity and secrecy. All non-public certificates will stem from this server. Most organizations choose to completely isolate their root CA for that reason and use another server, the subordinate CA, to sign certificate requests; The subordinate CA will sign certificates on behalf of the root CA.
In Windows, the certificate of the root CA is stored in the Trusted Root Certification Authorities store, while the certificate of the subordinate CA is stored in the Intermediate Certification Authorities store.

Certificates can be used in many scenarios, for example:
* If you want to encrypt files, you can use Encrypted File System (EFS) in Windows. EFS uses a certificate to protect your data from prying eyes.
* If you have a web server, you can use a certificate to establish a secure connection with a client so that all data is transferred securely.
* Stating the obvious: if you want to send email in a secure way, you can also use a certificate to achieve that

Not every certificate can sign code, encrypt files or send email securely. Certificates have a property, the Enhanced Key Usage (EKU), that states the intended purpose of a certificate. The intended purpose can be one of the actions mentioned above, or a wildcard. A certificate with only an EKU for code signing cannot be used to send email in a secure manner.

By disabling the “Secure Email” EKU from all certification authorities, except from our own root and subordinate CA, phishing mail that is signed with a valid certificate signed by a third party CA, will still trigger a warning stating that the certificate is invalid.
To do that, we must first discover all certificates that support the secure email EKU. This can be done with the following PowerShell one-liner:

# Select all certificates where the EnhancedKeyUsage is empty (Intended Purpose -eq All)
# or where EnhancedKeyUsage contains Secure Email
Get-ChildItem -Path 'Cert:\' -Recurse | Where-Object {$_.GetType().Name -eq 'X509Certificate2' -and ({$_.EnhancedKeyUsageList.Count -eq 0} -or $_.EnhancedKeyUsageList.FriendlyName -contains 'Secure Email')} | Select-Object PSParentPath, Subject

We now know which certificates support the secure email EKU. In order to disable to secure email EKU we have to do some manual labour. It is recommended to apply the following in a base image, group policy or certificate template.

  1. Run mmc with administrative privileges
  2. Go to File, Add or Remove Snap-ins, select Certificates
    B8TQT4f
  3. Select My user account, followed by OK. Please note that this mitigation requires that certificates in all certificates stores must be edited.
    CpRQtRz

    1. Check if intended purpose states Secure email or All
      175MRhH
  4. Open the properties of a certificate and click the details tab

If the intended purpose at step 3.1 stated All,
1. Click Key Usage, followed by Edit Properties.
iFPwV2x
2. Click Enable only the following purposes and uncheck the Secure Email checkbox
8nhvj29

If the intended purpose at step 3a stated Secure Email,
1. Click Enhanded key usage (property)
EHH4vBz
2. Click Edit Properties…
3. Uncheck the Secure Email checkbox
8nhvj29

Please keep the following in mind when implementing these mitigations:
* When a legitimate mail has been signed with with a certificate issues by a CA that of which the Secure Email EKU has been removed, the certificate of the email will not be trusted by Windows
* Changing the EKU may have an impact on the working of your systems
* These settings can be reverted with every update in Windows
* New or renewed certificates can have the Secure email EKU as well

This means that in order to only allow your own PKI server to have the Secure Email EKU enabled you must periodically check for certificates that have this EKU configured.

Human factor

With techniques like the one described in this blog post it becomes more and more obvious that users will never be able to withstand social engineering attacks. In a best case scenario, users will detect and report an attack, in a worst case scenario your users will become victim. It is important to perform awareness exercises and educate users, but we should accept that a percentage of the user base could always become a victim. This means that we (organizations) need to start thinking about new and more user friendly strategies in combating these type of attacks.

To summerize this blogpost:
* An email coming from a domain does not prove the integrity of the sender
* An email that is signed with a trusted and legitimate certificate does not mean that the email can be trusted
* If the domain of the sender address is correct and the email has been signed with a valid certificate signed by a trusted CA, only then the email can be trusted.

References

1: https://www.rijksoverheid.nl/onderwerpen/digitale-overheid/vraag-en-antwoord/wat-is-een-elektronische-handtekening (Dutch)
2: https://m2crypto.readthedocs.io/en/latest/howto.smime.html#m2crypto-smime “M2Crypto S/MIME”

Bitcoin Bomb Scare Associated with Sextortion Scammers

This blog was written by Jaeson Schultz.

Organizations across the country are on edge today after a flurry of phony bomb threats hit several public entities Thursday, such as universities, schools and news outlets, among others. The attackers distributed malicious emails claiming to have placed some type of explosive materials in the recipient's building. The emails stated the attackers would detonate these explosives unless the victim made a Bitcoin payment of several thousand dollars.

Cisco Talos discovered that this campaign is actually an evolution of sextortion and extortion attacks that we reported on in October. The claims in the emails we've seen from this actor are completely false, yet they have caused untold amounts of damage as organizations have evacuated buildings and called upon law enforcement to investigate.


An example of the malicious, phony emails that attackers sent out to organizations across the U.S. yesterday.


What makes these particular extortion messages unique from other extortion scams we've monitored is that, previously, the attackers threatened only the individual — the attackers would threaten to expose sensitive data, or even attack the recipient physically, but there was never any threat of harm to a larger group of people, and certainly not the threat of a bomb.

Talos has discovered 17 distinct Bitcoin addresses that were used in the bomb extortion attack. Only two of the addresses have a positive balance, both from transactions received Dec. 13, the day the attacks were distributed. However, the amounts of each transaction were under $1, so it is evident the victims in this case declined to pay the $20,000 extortion payment price demanded by the attackers.

So far, all of the samples Talos has found to be associated with the bomb threat attack were sent from IP addresses belonging to the domain registrar and hosting company reg.ru, suggesting that the attackers in this case may have compromised credentials for domains that are hosted at this particular domain registrar. Multiple IPs involved in sending these bomb threats also sent various types of sextortion email that we saw in the previous campaign. In those cases, the attackers sent out emails claiming to have compromising videos of the victim and will release them to the public unless the attacker receives a Bitcoin payment.

As of late yesterday, the bomb threat email attack morphed. The attackers have returned to their empty threats of harming the individual recipient. This time, they threaten to throw acid on the victim.


An example of the newer extortion emails, claiming they will dump acid on the victim unless they receive a Bitcoin payment.


So far, none of the Bitcoin addresses associated with these new emails have received any payments. The source of the sending IP addresses changed, however. This time, the attackers are making heavy use of IP addresses at the Russian hosting company TimeWeb. As with the bomb threats, these IP addresses belong to domains that the attackers likely compromised.

The criminals conducting these extortion email attacks have demonstrated that they are willing to concoct any threat and story imaginable that they believe would fool the recipient. At this point, we have seen several different variations of these emails, and we expect these sorts of attacks to continue as long as there are victims who will believe these threats to be credible, and be scared enough to send money to the attackers. Talos encourages users not to fall for these schemes and — above all — DO NOT pay extortion payments. Doing so will only confirm for the attackers that their social engineering approach is working, and victims' money goes directly toward facilitating additional attacks.

IOCs (BTC Addresses)

11B68RbmyxQys2CXXbAZxcwVXnaWCNBbw
12MET3CnEBkRc5Si5udf95fGaTZ6JwgpkK
132f8T1qF9hZj13MvPN5FbxrAhGExYZ7P3
149oyt2DL52Jgykhg5vh7Jm1QpdpfuyVqd
15F7TCqGRWE66xrBNxyt9ko1XsKaQvEh9t
15qH84uLC49CmC6jRE958Qjcf9WRZ2rMuM
1893DMwnrq9vA6JmQBdyWRKecArDAUTcGR
18UNWkvEDXgYzSAVnTmaR1X66w3T7HHsdn
1BTuxsCpAGtCzcszvFV2g4beqAZ2AUnyFh
1BfmmRBfhujpK944gai4vWvwCwGeHKbmkB
1BHasGex1jhRZeY7KyUGGKUNRtVgKedRY8
1CDs3JXUU6wNmndAF7EFcrJ6GGSYRKXd7w
1CF9VQhwjJutPxwVq5QLFA7j7baq4RDb3w
1CXrmcKL7W2o6FnrFx3ZBGn2EAsbMVZMzD
1CdD3nthrWR76RkL1WwLH7BSqCFASLjbhu
1D3ArQebDneVBVCqLort9jwvUA3AoZaNq5
1DVVQpxF4nG7rmuQFb7ZboGxu6ahKJcjf5
1Dnw2qJxGFCZdE3PzCaVioBB9zERc7SzRB
1DRXeydtqfjAmvfrLY7XiCo2A1vCq32z3a
1Ebf2rrLxVuMGKkwi2PeZtjBEEiidxrkkL
1FnTQHffH42iS15FMYNZxmNdbXtmb8WChF
1GTd6DPqcxCwX263BMsvk7FcjCQxsXhJUs
1GYAJY3GRsC5twdPgmQiEeNjdn7Kx6KSPd
1L5SWCu4ZTLiyPyTAvfSVjhKrYNSnYgBKk
1LEevM4MxKSGRrTvVrvLyjiuq3vYssdTRa
1LT4WgSuTD71Emzc7DLeHxVoZ1RjkhNcFY
1LTYBLzVSLe6GDFJ5NVVxLR2j5eQ8Wy51N
1LjxZonruwcKXEUYySrXt7gWGJLL6Pzuyx
1M9r1FpWj5QbSMECeJvXoa85TDMpoQcRaT
1MeDDtvZB5TE5tDTcwk6GiGSK3sTAP2KLA
1P3cNFy3SdfZ8PvMSdgLRcb2TtaLvxfqat
1PqX7bMnCzpJ7L1mxuGgNyaJSkJRM8SjES


Coverage


NBlog Nov 22 – SEC begets better BEC sec

According to an article on CFO.com by Howard Scheck, a former chief accountant of the US Securities and Exchange Commission’s Division of Enforcement: 
"Public companies must assess and calibrate internal accounting controls for the risk of cyber frauds. Companies are now on notice that they must consider cyber threats when devising and maintaining a system of internal accounting controls."

A series of Business Email Compromise frauds (successful social engineering attacks) against US companies evidently prompted the SEC to act. Specifically, according to Howard:
"The commission made it clear that public companies subject to Section 13(b)(2)(B) of the Securities Exchange Act — the federal securities law provision covering internal controls — have an obligation to assess and calibrate internal accounting controls for the risk of cyber frauds and adjust policies and procedures accordingly."
I wonder how the lawyers will interpret that obligation to 'assess and calibrate' the internal accounting controls? I am not a lawyer but 'assessing' typically involves checking or comparing something against specified requirements or specifications (compliance assessments), while 'calibration' may simply mean measuring the amount of discrepancy. 'Adjusting' accounting-related policies and procedures may help reduce the BEC risk, but what about other policies and procedures? What about the technical and physical controls such as user authentication and access controls on the computer systems? What about awareness and training on the 'adjusted' policies and procedures? Aside from 'adjusting', how about instituting entirely new policies and procedures to plug various gaps in the internal controls framework? Taking that part of the CFO article at face value, the SEC appears (to this non-lawyer) very narrowly focused, perhaps even a little misguided. 

Turns out there's more to this:
"As the report warns, companies should be proactive and take steps to consider cyber scams. Specific measures should include:
  • Identify enterprise-wide cybersecurity policies and how they intersect with federal securities laws compliance
  • Update risk assessments for cyber-breach scenarios
  • Identify key controls designed to prevent illegitimate disbursements, or accounting errors from cyber frauds, and understand how they could be circumvented or overridden. Attention should be given to controls for payment requests, payment authorizations, and disbursements approvals — especially those for purported “time-sensitive” and foreign transactions — and to controls involving changes to vendor disbursement data.
  • Evaluate the design and test the operating effectiveness of these key controls
  • Implement necessary control enhancements, including training of personnel
  • Monitor activities, potentially with data analytic tools, for potential illegitimate disbursements
While it’s not addressed in the report, companies could be at risk for disclosure failures after a cyber incident, and CEOs and CFOs are in the SEC’s cross-hairs due to representations in Section 302 Certifications. Therefore, companies should also consider disclosure controls for cyber-breaches."
The Securities Exchange Act became law way back in 1934, well before the Internet or email were invented ... although fraud has been around for millennia. In just 31 pages, the Act led to the formation of the SEC itself and remains a foundation for the oversight and control of US stock exchanges, albeit supported and extended by a raft of related laws and regulations. Todays system of controls has come a long way already and is still evolving.

NBlog Nov 20 – go ahead, make my day


What can be done about the semi-literate reprobates spewing forth this sort of technobabble nonsense via email? 
"hello, my prey.
I write you since I attached a trojan on the web site with porn which you have visited.My malware captured all your private data and switched on your camera which recorded the act of your wank. Just after that the malware saved your contact list.I will erase the compromising video records and data if you pay me 350 EURO in bitcoin. This is wallet address for payment : [string redacted]
I give you 30h after you view my message for making the transaction.As soon as you read the message I'll know it immediately.It is not necessary to tell me that you have paid to me. This wallet address is connected to you, my system will delete everything automatically after transfer confirmation.If you need 48h just Open the calculator on your desktop and press +++If you don't pay, I'll send dirt to all your contacts.      Let me remind you-I see what you're doing!You can visit the police office but anyone can't help you.
If you try to cheat me , I'll see it immediately!
I don't live in your country. So anyone can not track my location even for 9 months.Goodbye for now. Don't forget about the disgrace and to ignore, Your life can be destroyed."

It's straightforward blackmail - a crime in New Zealand and elsewhere - but the perpetrators are of course lurking in the shadows, hoping to fleece their more naive and vulnerable victims then cash-out anonymously via Bitcoin. Identifying them is hard enough in the first place without the added burden of having to gather sufficient forensic evidence to build a case, then persuade the authorities to prosecute.



So instead I'm fighting back through awareness. If you receive vacuous threats of this nature, simply laugh at their ineptitude and bin them. Go ahead, bin them all. Train your spam filters to bin them automatically. Bin them without hesitation or concern. 



Then, please help me pass the word about these ridiculous scams. Let your friends and family (especially the most vulnerable) know. Share this blog with your classmates and work colleagues. Send journalists and reporters the URL. Hold a bin-the-blackmail party. 

By all means call your national CERT or the authorities if that makes you feel better. Just don't expect much in the way of a response beyond "We're inundated! Sorry, this is not a priority. We simply don't have the resources."

If enough of us call their bluff, these pathetic social engineering attacks will not earn enough to offset the scammers' risks of being caught ... and who knows, we might just draw some of them into the open in the process. Let's find out just how confident their are of their security, their untraceability and invincibility. 

Recite after me: "Go ahead, make my day ..."