For pity's sake, groans Mimecast, teach your workforce not to open obviously dodgy emails

A JavaScript-based phishing campaign mainly targeting British finance and accounting workers has been uncovered by Mimecast. The attack, details of which the security company published on its blog, "was unique in that it utilized SHTML file attachments, which are typically used on web servers". When the mark opened a phishing …

[Anonymous Coward]

you could do that, but...

The record is clear that "employee training" does not work well. Partly this is because of box-ticking exercises, but also it is because it takes only a single incident to cost a company a huge sum of money (and possibly damage to its reputation). I'd suggest that a better option is to provide the great majority of employees, most especially those in accounting, finance, payroll, AP, AR, HR, and other internal departments, with internal-use-only accounts that cannot send or receive mail outside the company. Invoicing and similar tasks can be completed using fax or postal mail, as they always have been and as every company is set up to handle anyway. The only employees who are likely to need outside email access in most companies are the sales team, and they need to have their accounts set up with the strictest imaginable settings and receive at least weekly anti-phishing tests (no pass, no pay; salescritters are easy to motivate, and besides that most of the scams will be obviously irrelevant to someone in that role). And since they don't normally have access to the company's accounts, even when they do inevitably fall for some scam it shouldn't do much damage.

In principle, humans are smart enough that this crap should never work. In practice, it's apparent that any collection of 10 or more humans likely has at least one who isn't. Let's be data-driven in our approach to security.

[P. Lee]

Re: you could do that, but...

The same goes for browsers. There should be a way to change the security context which the OS provides to the browser so that "internal domains" and external domains are treated differently. The code which identifies URLs and launches the browser needs to be involved in selecting the correct security settings. Maybe external domains get a containerised/vm version running off a RAM disk OS.

User-account-based security is not enough. This is an OS development failure, an especially egregious failure by those who charge for their OS.

[Anonymous Coward]

Re: you could do that, but...

You can get off your high penguin because even VMs won't save you from some Spectre-type attacks. So you gonna bitch now about those who charge for their CPUs?

[Doctor Syntax]

Re: you could do that, but...

What penguin? The OP mentioned no OS by name and the point is a good one. We need to seriously rethink desktop OS design amongst other things.

From what I've read Qubes OS seems to be a good start but I'd go a lot further. Do we need, for instance, an all-powerful user ID? Perhaps one user ID can handle disk partitioning but not have permissions to read disk contents. Another is responsible for installing applications and another manages user IDs. Another has permissions to structure a disk partition as a database and provide storage and retrieval systems as a service. Ordinary users don't get to access that database, their applications ask the server to store and retrieve files. Preferably some sort of authorisation could be devised so that the server recognises not only the user on whose behalf the request is made but also the application. Less convenient but then security is often a trade-off with convenience.

[Anonymous Coward]

Re: you could do that, but...

That sounds awfully complex and error-prone. How about instead we just put all their network drops / WAPs on an internal-only network and tell the router they can't access the Internet? Done and dusted. As a bonus, we can hire half as many of them because they won't have as many ways to waste time.

[matjaggard]

Re: you could do that, but...

No internet access is almost what my firm has done. Far from making them more productive, the impact on not being able to look at documentation and user groups is immense, especially for developers.

[NetBlackOps]

Re: you could do that, but...

This engineer doesn't use shit that only has online documentation. And that's exactly what that is.

[jake]

Re: you could do that, but...

You need new developers.

[Oliver Mayes]

Re: you could do that, but...

Sorry grandpa, the world has changed. Every developer here (me included) refers to online documentation, it's far more efficient than expecting everyone to just remember thousands of function names and exactly how every one works.

[Doctor Syntax]

Re: you could do that, but...

Copy the online documentation to a local server.

[jake]

Re: you could do that, but...

But Dr.S, then they would have to continue working when TehIntraWebTubes was down! Can't have that, now can we?

[jake]

Re: you could do that, but...

Perhaps when you're old enough to be called "grandpa" (and have a laugh at the child who thinks that it is an insult) you'll understand why several more years experience helps you remember all those terribly difficult to memorize functions.

[Doctor Syntax]

Re: you could do that, but...

Enough years more experience has the opposite effect.

Sic transit gloria mundi (basis of the best of all Carry On puns.

[jake]

Re: you could do that, but...

I haven't seen that many years yet. Let me know when I have, as I'll probably miss it ;-)

I counter with dum vivimus vivamus (the basis on which I try to live my life).

[BrownishMonstr]

Re: you could do that, but...

You don't even need a non-smart person, you just need a smart person to have an "Ohfuck" moment.

[Allan George Dyer]

Re: you could do that, but...

@BrownishMonstr - 'you just need a smart person to have an "Ohfuck" moment'

I totally agree. I think it's useful to look at the junk that didn't fool you, and actually think about who it's likely to fool. For example, from my own inbox:

'[Linkedln Notification]: Order Proposal sent to XXX@XXX, -Message ID Ref: UD93013A03].': Sales

'Shipping 顺丰电子发票通知': Purchasing

'View Share Document 6547839': Marketing, Management

'您的包裹无法送达': Shipping

'Re: Proforma Invoice No.10677 ~ Pending Confirmation': Accounts

Phishers intentionally craft messages to mimic genuine important messages, who would have guessed? The tricky part is remembering that when your tired and under pressure.

[gnarlymarley]

Re: you could do that, but...

The tricky part is remembering that when your tired and under pressure.

This is my problem. Management as my work want to bring costs down, so they try to get their salary folks to work the overtime. Obviously, this causes mistakes. Once we hit a mistakes threshold, they switch over to hourly people working the overtime. If we go below the threshold, they switch back to salary people. (Maybe I should make more mistakes on overtime, so my time is less.......)

[Ken Hagan]

Re: you could do that, but...

"The only employees who are likely to need outside email access in most companies are the sales team"

I'm pretty sure most R&D folks and most marketing types and most HR staff will have sent and received legitimate emails to and from external addresses at some point. I know I do. We have things like suppliers and sub-contractors to deal with.

[Anonymous Coward]

Re: you could do that, but...

The evidence does not lie. While most people are not vulnerable to these attacks, some are. Your company does not have an effective means of screening them out of the hiring process, and training/education have proved generally ineffective. In many jurisdictions the kind of employment contract terms that would be needed to create the proper incentive structure are forbidden by law. What's left is shrinking the attack surface to the greatest practical extent. That means no communications for most employees and extremely strict controls on those who cannot do without, usually some combination of whitelists, 2-person (or more) controls, and frequent testing with severe penalties for failure. Your intermediate goal is to make applying for access an absolute last resort, something employees dread viscerally and will do only when they have exhausted all other possible ways to get the job done. They should come to you begging to turn it off once the need has passed. Similar rules should apply to inbound telephone calls, which pose a similar threat and were the principal medium for phishing (then called "social engineering") before the age of email.

[Anonymous Coward]

Re: you could do that, but...

I've seen scams, fake invoices, etc etc posted. As in snail-mail. And faxed, but nobody uses fax now anyway. Yes, there's a higher cost involved for the scammers, but that also helps convince the marks that it's genuine.

Changing what media is available will not change which scams are attempted.

[jake]

Re: you could do that, but...

"Changing what media is available will not change which scams are attempted."

But we can make our systems less vulnerable, right?

Note that it's not simply "a higher cost", it's several (many?) orders of magnitude higher cost to use the non-email variations on the theme. That's why they use email. It costs them just as much to send 10 as it does to send 10,000,000 ... all at one push of a button. Con artists are lazy ... and cheap.

(Yes, people still use faxes. They are actually quite common.)

[Mr Humbug]

Re: you could do that, but...

It's orders of magnitude higher cost, but it seems it must work. If it did not then "Domain Resgistry of America" wouldn't send out invoices to renew your domain's "internet search registration"

[lglethal]

Re: you could do that, but...

"The only employees who are likely to need outside email access in most companies are the sales team"

Wow, what sort of firm do you work in? I take it your firm has no suppliers, customers, partners or collaborating firms? That must be nice.

I'm just an engineer, but I'm regularly in direct contact with my equivalents in our suppliers, partners and customers in order to send or receive the details we all need in order to make our projects work. I cant imagine how badly a project would get f%&ked up if all details could only be passed through the snake oil men (sorry sales).

[jake]

Re: you could do that, but...

As I said in the other thread, all you have to do is make a business case for that access. Sorted.

[Doctor Syntax]

Re: you could do that, but...

"The only employees who are likely to need outside email access in most companies are the sales team"

Sales and marketing are the worst offenders in what they send from their businesses. They are the most addicted to sending HTML mail, the worst for embedding links and apt to use outside agencies so that the actual domain from which mail is sent isn't their own and the embedded links are also likely to belong to a different domain. In short their emails look exactly like phishing emails.

They expect other people to open their emails so why wouldn't they open those with exactly the same characteristics?

[MJB7]

Re: you could do that, but...

Accounting needs to talk to the vendors, customers, auditors

Finance needs to talk to banks

HR needs to talk to potential employees

Our company (admittedly small, but a datapoint) has no access to fax so a big company which can't do email will just be ignored as a vendor. (We might live with them as a customer, because - money.) Traditional post is a joke, right?

Good end-user training is not a silver bullet, but it does help. Layers of defence internally; internal 2FA; multiple authorization etc help too.

[jake]

Individual people can be smart.

However, people as a group tend to be ineducable.

The easiest solution is to not allow email and Internet access to the vast majority of employees. When you think about it, most people have absolutely zero use for the Internet in their day to day corporate work anyway, so this is no great loss. In fact, getting rid of access to timewasters like twitter, facebook, instagram, youtube, amazon, google and the like can only increase corporate productivity.

Of the remainder, tell 'em that opening and/or responding to such emails is a firing offense. No exceptions. Help the insanely curious amongst them along by setting your MTA to keep a close eye on attachments and links in email, and beg steal or borrow an extensive block list for the rest of the Internet.

More draconian (perhaps, this is work, not play-time!) I've actually had some luck with whitelisting corporate Internet access for the subset of employees who actually need Internet access. If the user can't make a business case for accessing a site, then that user can't access the site. Whitelisting is a bit of a pain to set up at first, but after the first week or so it pretty much runs itself. Try it before you poo-poo this.

[NetBlackOps]

Re: Individual people can be smart.

Back when I was running such things, everything was done by Whitehouse and consumed very little of my day to day time despite being pretty permissive and counting fatherly talks. Worked surprisingly well.

[Anonymous Coward]

Re: Individual people can be smart.

You must not run a union shop.

[jake]

Re: Individual people can be smart.

Of course I don't run a union shop, silly! I work in the 21st century, not the 19th.

[Mr Humbug]

Re: Individual people can be smart.

> tell 'em that opening and/or responding to such emails is a firing offense.

The trouble with that approach is that at some point someone will make a mistake. When they do, would you like them to report it so that you can respond as quickly as possible, or would you like them to keep quiet and try to conceal it?

Of course you then have to decide whether that will work in your company's culture and with the people you have working there. And that will be affected by whether they see themselves as part of the business or as someone who turns up to complete a task and then go home.

[MisterHappy]

How scalable is this though?

Just from curiosity, how many 1000's of people do you administer in this manner? I can see it being workable for a small company but when the employee count is in the several thousands wouldn't it become an administrative overhead.

Add to that that a lot of companies (if not most) have a YouTube, Facebook & Twitter presence it becomes a lot harder to restrict access when the propaganda dept keeps sending out encouragement to "Check our social media sites".

We send out our own internal phishing emails every now and again, to different subsets of end users, with different levels of believability & we keep track of who reports them & who clicks on the link and enters any information. The only thing that has seemed to work was the threat of naming and shaming as part of the follow up.

[Throatwarbler Mangrove]

Mimecast

You would think they'd keep quiet about this sort of thing.

[Anonymous Coward]

Mimecast can not secure their own domain

mimecast domain :

secure DNS - No

secure MTA-STS - No

secure TLS DNS records - No

basic failures if it was just one, excusable but all of them, not trustworthy at all they just want to invoice...

[julian_n]

That phishing snapshot looks to have been translated from French - card and map are the same word in French - carte - hence the mistranslation on the last line.

Now which countries use French?

[jake]

"Now which countries use French?"

France, Switzerland, Belgium, Canada, Louisiana (yes, it is too it's own country! Ask 'em if you don't believe me) ... I'm sure I missed a couple ;-)

[James O'Shea]

You missed quite a few. Algeria, Tunisia, Morocco, Senegal, Niger, Burkina Faso, Chad, Mali, Central African Republic, Côte d'Ivoire, Congo (both of them), Tahiti, New Caledonia, Martinique, Guadeloupe, Guiana (not Guyana, they speak English there), Vietnam, Cambodia, and possibly more. Note that the level of Frenchiness may vary from Côte d'Ivoire which has insane levels of Frenchiness even for French Puppet Africa (look at the name!) to Vietnam and Cambodia where Frenchiness is not loved.

Exits, to Le Boudin.

[Charlie Clark]

Just use text/plain

The problem is the use of HTML in e-mails in the first place. There is no need for it as text/plain is sufficient for all communicative needs. If people can't piss around with the formatting and don't top post, they might spend a little more time thinking about what was written and what they want to say. Instead bad practices and solutionism have led to the rise of Slack, et al.

Mine's the one with Tenenbaum's book on operating systems in the pocket.

[Doctor Syntax]

Re: Just use text/plain

A good start would be filters on MTAs which bounce - with appropriate error messages - HTML mail.

[SeanEllis]

People can't be trained to deal with this threat. If they could, it wouldn't be a threat by now.

More concerningly, why is Javascript even allowed in work email? Or in PDFs? Or even on web pages?

At work, turn everything "smart" off, and lobby for essential websites to stop loading scripts from 30 domains just to show me a press release or a page of documentation.

NoScript, AdBlock, Cookies off.

[Anonymous Coward]

I've been thanked a few times by the firewall/security bods for forwarding them dodgy emails but I almost failed a company mandated anti-phishing test because it was frankly pants! (passmark was 80% and got exactly 80%)

I rejected one example as 'dodgy email address' because it was directing me to log on to an unrelated site but was told I was wrong because their reasoning was that it was dodgy because of poor spelling.... unfortunately I had been desensitised to poor speeling/grammer/punctuation's because of a previous manager (typical sign off "Thanks You") and from offshored departments asking me to 'do the needful'

[Anonymous Coward]

The problem here is not with people opening obviously dodgy emails, but with people opening obviously dodgy email *attachments*. There must surely be tools available to either run a security scan on any attachment a user attempts to open from their email client, or a way to disable the opening of attachments from email clients? With the ability to set exceptions for those employees who really need to handle documents sent by email from outside the organisation?

[Anonymous Coward]

Little reason for staff to personally give a ****

I've been saying for years that if staff are found stealing a stapler, they are treated more severely than if they cause an infection, loss of data or financial fraud as a result of clicking on clearly fake e-mail.

Cost to the organisation from infection of a single PC can run into thousands in IT staff time, investigation etc. In almost 20 years I have never seen anyone fired for even blatant stupidity whilst using computers.

I have however seen them fired for breaking equipment, losing equipment etc costing far less.

[herman]

Blaming the User

The age old IT defence is to blame the user.

Links are to be clicked. Attachments are to be opened. Dissemination of information is the whole purpose of the email system.

The computers should not be affected by messages and their content. A proper implementation of MAC, as on UNIX/Linux/Mac will assure this.

[David Lawrence]

Point of detail please....

In the article the wording seems to imply that simply OPENING the email does the damage. Is that correct? As far as I am aware the damage only happens when the carbon-based retard 'opens' the ATTACHMENT that is embedded in the email, or clicks on the link.

You may think this is a minor point, or nit-picking but it is very important that people (especially the carbon-based retards) understand where the risk really is. They struggle enough as it is, bless them. Of course, if people really have found a way to launch an attack when a user simply OPENS an email then I stand corrected and expect the downvotes.

[deep_enigma]

Re: Point of detail please....

Unfortunately, yes, depending on the specific phish it is possible that just opening the message is enough to cause trouble.

The problem is what I consider a design defect in most mail clients - the fact that they execute Javascript in the HTML part of the message. It's one of the very first things I do on the occasional new install of Thundebird or Seamonkey - go into the settings, and turn off Javascript support in the email handling. I can't imagine any valid use case for it - if anything really needs that degree of complexity, it should be hosted on a normal web site, and handled by a full web browser.