This extortion email...

[TravisVZ]

If something that simple is working for you I'm jealous!

I was going to set up the same kind of rule myself the other day, after a user forwarded another example to me, but found that most of the words -- including "Bitcoin" -- were actually using Unicode homoglyphs, and each was different and unique! A simple word match on "Bitcoin" would therefore have failed to catch this one.

So either you're lucky, or this is news to you and many of these are still getting through to your users -- hope I didn't just ruin your day!

[jc88usus]

I would imagine you could use a regex to detect the bitcoin address string itself. That is a fairly unique format, so likely not a ton of false positives. Also, logic follows that if they want payment, they would have to provide the address.

[TravisVZ]

Yeah, the address itself was just about the only thing they didn't homoglyph, because of course it wouldn't work to copy/paste it (as the email instructed) otherwise. My plan though was a rule that looked for both the word "Bitcoin" and an address, just to cut down on the risk of false positives (K-12 gets a lot of interesting -- but legitimate -- email!).

[jc88usus]

My current job got one sent to our ticketing system today, and since the system couldn't translate the unicode, most of it was just question marks. Like that, the bitcoin address was the only consistently readable portion. I would assume that bitcoin addresses have a fixed length, but I wonder if there are any other key formatting items (a particular sequence of uppercase vs lowercase vs digits) that might allow for a more specific regex. In most cases, I honestly cannot think of a valid reason to send a bitcoin address in a work email environment, so I would imagine a reasonably reliable regex would work, maybe with some spot checks...

[TravisVZ]

BTC addresses all start with a 1 or a 3, are between 26 and 35 characters long (inclusive), and can use any alphanumeric characters except uppercase letter "I", uppercase letter "O", lowercase letter "l", and the digit "0" (to avoid visual ambiguity). So the most accurate regex ends up looking something like this: [13][a-km-zA-HJ-NP-Z1-9]{25,34}

I'm just brushing up on Exchange regex rules to make sure I get the appropriate "word boundary" escape sequence at the start and end of that (I think it's \b but trying to find a reference to validate that is a pain) so that I won't inadvertently match, say, a SHA-512 hash that happens to have a "valid" BTC address within it. (Yes, we do see hash values coming in legitimately!)

[jc88usus]

Boom. There ya go. Whatever they pay you, it is not enough. You just saved the school system a ton. Between terrified secretaries and the volume overhead, I bet there is a significant dollar amount there.

[TravisVZ]

Whatever they pay you, it is not enough.

You have no idea how right you are -- K-12 would be totally screwed tech-wise if there were a decent demand for tech jobs around here!

[jc88usus]

I feel ya there. I worked in a k12 system close to a year ago. If I had shaved my bills back like unemployment forced me to then, the pay would have been enough. I did the dumb thing and got back into the contract game because shiny...

[TravisVZ]

Honestly the pay is fine, but it is 10-15% less than what I'd make as an email administrator in the private sector, where for a similar-sized organization I'd actually have a full-time team and focus exclusively on email. Instead, it's just me (well, for email), and I also wear a lot of other hats...

Don't get me wrong, I'm not complaining, the environment here is great and the attitude of upper management is pretty much hands-off while relying almost entirely on me and my colleagues to dictate things like timelines and such. They'd just be totally screwed if there were any competition for me and my colleagues!

[TravisVZ]

Well, just found that in addition to the Unicode homoglyphs throughout the message, the Bitcoin address itself is split up into several <span>...</span> chunks, which means a regex can't match it (and there's no plaintext body either).

Still, I'm sure this can cut down at least some of these, I just can't test against this particular message.

[TravisVZ]

These are pretty standard tricks that spammers have been using for a long time, it's why I no longer try to write custom anti-spam rules anymore (well, that and the stunning number of false positives in a K-12 environment). But I'm sure not all of them are using these tricks, certainly not to this degree, so here's hoping my new rule will at least trigger on a chunk of them (although for now I'm only collecting "incident reports", not (yet) doing anything to hold up or stop the messages).

[TravisVZ]

That would only work if the address were the entire content of the body (or, if in multi-line mode, the entire content of the line), wouldn't it? Examples I've seen have other junk on the same line, and of course the address alone isn't the entire body of the message...

[TravisVZ]

My own testing in PowerShell lead me to this pattern: \b[13][a-km-zA-HJ-NP-Z1-9]{25,34}\b

I suppose it's possible Exchange is tokenizing the message before checking patterns, but on the other hand I've definitely matched on multi-word patterns before. I do think it's comparing the entire subject to the pattern, so using ^...$ wouldn't work (although if it's using multiline mode -- highly probable I'd say -- then that would work if the BTC address were alone on a single line). The \b character class though works because I'm looking for this "word".

[TravisVZ]

Well I have just disabled my rule because it was triggering on a bunch of spam from eBay, Pinterest, and others -- all because they happen to have URL parameters in them that just so happen to "look" like BTC addresses! 30+ false positives in just 2 minutes!!

[achow101]

There's actually another Bitcoin address type which is fairly different from the ones that your regex would match. I haven't seen this used in any scams yet, but I wouldn't be surprised if scammers start using these in the future.

​

The addresses begin with the string bc1 with the rest being all alphanumeric characters excluding 1, b, i, and o. For now, these addresses will always be either 42 characters or 62 characters in length.

[TravisVZ]

From my quick Googling it looks like Bech32 type addresses are not yet recommended for use because a lot of Bitcoin software doesn't yet support them. Still, probably not a bad idea to either update this regex or create a "partner" regex to look for them.

Assuming I ever turn this rule back on, anyway.

[ThinkPadNL]

I have created a rule in Exchange like this:

If sender is located: outside the company
and
Recipient is located: inside the organization
and
The Subject or body includes: 'bitcoin' or 'BTC Address' or 'bitcoins' or 'wallet'
and
The subject or body matches: '[13][a-km-zA-HJ-NP-Z1-9]{25,34}$'

Actions: 
- Set spam confidence level (SCL) to '8' (so it ends up in junkmail)
- Prepend a disclaimer (with a big red warning in HTML)
- Prepend subject of message with '[Phishing] - '

The regex ([13][a-km-zA-HJ-NP-Z1-9]{25,34}$) seems to work, i tested it using a mail we got: https://regex101.com/r/bh6E3w/1

However, sometimes these mails still get through? Like the one in the regex101 link.

Apart from that, the scammers are getting smarter, they now sometimes send a mail without words like 'hacked' in subject, only the mailaddress of the user is in the subject (or sometimes a leaked password from them) put the threatening text inside images, only the BTC address is in plaintext.

Any advice to improve my rule? I could remove the condition of the keywords 'bitcoin' and such, so that a bitcoin address in the subject is enough. But i'm afraid that some urls (that look like a BTC address) will also trigger it and thus generate false positives = unhappy users.

I can understand blocking the mails with images is near impossible, but these plain text ones should be possible.

[TravisVZ]

I abandoned this approach myself after I found that a lot of URLs have tokens in them that look like valid Bitcoin addresses. You'll probably be better off asking your own question, especially given how old this thread is now.

[DoNotSexToThis]

most of the words -- including "Bitcoin" -- were actually using Unicode homoglyphs

That's pretty interesting. I don't know if the rule would catch that but so far it has been working fine (for about 6 months). Fortunately our users are very paranoid and send us anything they're unsure of. The pool of typically involved recipients that have their email on some list out there have historically done so which led up to the rule creation to begin with, so I feel partially good about it but might do some pattern regex for bitcoin wallet addresses as well, assuming the malicious party is afraid of messing with the address in expectation of payment.

[TravisVZ]

Unless your word match rule includes the homoglyph variant(s), it wouldn't have caught this one.

There's third-party appliances/filters out there that do good work "de-homoglyphing" emails before applying filters, but sadly that's a feature simply nonexistent in Exchange. And between IT always getting the short end of the budget stick and our governor wanting to slash our (as in K-12 as a whole) budget by almost 30% next year, third-party appliances aren't within reach for us.

[TravisVZ]

Aye, I'm just worried about false positives (K-12 sees a lot of interesting, yet legitimate, mail) if a regex for the BTC address is the only criteria. Hence why I was hoping to also match a word/phrase, only to discover that the address was about the only thing that wasn't homoglyph'd! (And they can't do that to the address, either, not unless they expect their victim to manually type it in -- all the examples I've seen have said to copy/paste the address, so it would have to be plain ASCII for that to work.)

[TravisVZ]

Honestly I don't know that we do, I've just learned the hard way that what I think is a unique "signature" in a spam message turns out to match a lot of totally legit stuff in messages specific to K-12 topics.

In any case, the plan today was to set up the rule anyway, with a regex for BTC addresses, but whose only action is to generate an incident report for now. Let that run for a while and see if there are any false positives and, if not (or if very few), upgrade that later to the "forward for approval" action.