Tag Archives: social engineering

Social Engineering and Ransomware

SecurityWeek contributor Kevin Townsend asked me about a report from the UK’s De Montfort University on the psychology of ransomware splash screens. Here’s the article he published – Researcher Analyzes Psychology of Ransomware Splash Screens – and here are some further thoughts from me published on the ESET blog: Social engineering and ransomware.

David Harley

Ransomware targeting schools

Action Fraud warns that:

Fraudsters are posing [as] government officials in order to trick people into installing ransomware which encrypts files on victim’s computers [by] …cold calling education establishments claiming to be from the “Department of Education”. They then ask to be given the personal email and/or phone number of the head teacher/financial administrator.*

They claim that they need to email guidance to the person in authority because of sensitive comment. However, the attachment contains ransomware.

* Contains public sector information licensed under the Open Government Licence v3.0.

Commentary by Graham Cluley for BitDefender: Schools warned about cold-calling ransomware attacks

David Harley


Support Scam Threatens to Delete Hard Drive

Siddhesh Chandrayan, for Symantec, reports on a particularly vicious example of social engineering designed to scare a victim into ringing a fake support line:

Tech support scams increasing in complexity – Tech support scammers have begun using code obfuscation to avoid detection.

The pop-up fake alert claims that the victim’s system is infected with ‘Exploit.SWF.bd’ and that the hard drive will be deleted if he or her tries to ‘close this page’. It displays a fake ‘hard drive delete timer’ complete with audio effect.

Don’t panic! In principle, Javascript like this isn’t able to do any such thing: that’s a security feature of the language. (There are, of course, other ways of accessing and changing the contents of a client-side disk, but there’s no suggestion that any of those mechanisms are at play here.)

The obfuscated script also includes code to ascertain whether the system is running Windows, ‘MacOS’, UNIX or Linux, so that the alert can be tailored accordingly.

Commentary by David Bisson, writing for Graham Cluley’s blog: Scare tactics! Tech support scam claims your hard drive will be deleted – Scammers tries to frighten you into phoning them up.

David Harley

Ransomlock.AT: ransomware meets support scams

It’s been a while since I’ve had occasion to talk about the issues that sometimes link tech support scams and ransomware, but now a couple of relevant items have come along more or less simultaneously. First, let’s look at the malware Symantec calls Trojan.Ransomlock.AT.

Symantec describes ‘a new ransomware variant that pretends to originate from Microsoft and uses social engineering techniques to trick the victim into calling a toll-free number to “reactivate” Windows.’ (That is, to unlock the computer.) The article is here: New ransomware mimics Microsoft activation window. The Symantec researchers tried to contact the ‘helpline’ number 1-888-303-5121 but gave up after 90 minutes of on-hold music and messages. Interestingly, a web search for that number turns up dozens of links to sites claiming to help ‘remove’ the number, which Symantec believes to have been promoted by the ransomware operators or their affiliates.

Fortunately, they spent less time on concealing the unlock code, for the moment at any rate. Symantec tells us that ‘Victims of this threat can unlock their computer using the code: 8716098676542789’.

Beating the ‘Microsoft scam’

On the SC Magazine web site, Biocatch’s VP of Product Management Oren Kedem asks ‘After a decade, why can’t we finally be rid of the Microsoft scam?‘ Which is slightly odd, in that he reckons the support scam (no, he wasn’t talking about the way Microsoft is pushing Windows 10!) has been around since ‘at least 2009 in one form or another’. Well, I first heard about it in 2010, but Steve Burn, something of an authority on the sites that push these ‘solutions’, has indeed been following them since 2009. Still, that’s rather less than a decade.

That doesn’t invalidate Kedem’s central point, though. In spite of all the publicity we’ve given to these scams, they’re still clearly operational. While much of the action has shifted away from cold-calling to decoy popups and fake alerts, seeding undesirable URLs via SEO and social media, and even real malware, I still see reports on the ESET blog from people who’ve fallen for tricks like the old CLSID gag. Of course, they haven’t necessarily been cold-called, but the scammers are clearly still using tried and tested gambits to ‘prove’ that the victims need their help.

Kedem suggests that education fails because people fly into a panic and forget what they’ve been told when a scammer actually captures their attention. There’s probably something in that, but in my experience people tend to be fairly good at spotting a scam that’s close to something they’ve previously been warned about. However, they’re not so good at extrapolating from one scam to another when the underlying mechanism is the same, but the gambit used appears quite different. Which is why I try to demonstrate attack principles as well as just describing an attack. (That often goes for technical attacks as well as social engineering.)

Unfortunately, support scam attacks have proved fairly adaptable over the years. While the scammers themselves are often far from bright, the scripts they work from are sometimes pretty clever. (Fortunately, a not-so-bright scammer will very quickly sound much less convincing if you nudge them away from the comfort of an anticipated response.  They’ll tend to desperately try to get you back on script, often by ignoring awkward questions and repeating scripted material until it’s clear they’re not going to get anywhere.) Still, the social engineering gambits they use in those scripts (and even the more technical approaches we’ve seen recently) are often far brighter than the call-centre drones that deliver them.

Kedem does make an interesting suggestion about making bank employees identify themselves with a ‘code of the month’ which might have possibilities for reducing phishing. Unfortunately, I can’t see how it would help with the ‘Microsoft scam’. And while there are ways of implementing educational programmes that might have more impact, getting the home users who are the main targets of support scamming to undergo suitable training may not be so easy.

David Harley

VB Seminar 2010

I spoke at the VB 2010 Seminar in London on ways that Social Engineering can affect your business’ users.

During the talk, I used some links for demos (many thanks to my good friend Dave Marcus for originally showing me a few of these). For those that are interested, here are the links:


Andrew Lee

Breaking up is never easy…LoveBug, the day after.

The LoveBug/Loveletter/Iloveyou worm (much more geekishly called VBS/Loveletter.a@mm by, well, AV geeks) has become one of those legendary events in malware history. The fact that 10 years on we’re still writing about it. Not only that, but many of us will remember exactly where we were and what we were doing when we first heard about it – in fact many more might remember it than were actually there :).

Still, I remember exactly where I was – I was in Reading, at Microsoft headquarters attending a security seminar and my Blackberry (one of the very early ones, with a greyscale LCD screen), started to go off regularly. I grabbed the next train back to Dorset, got into work, and spent the next ten hours ensuring that nothing bad was going to happen on our network. Many other people have written about their memories of the day – 10 years ago yesterday – including Graham Cluley and Mikko Hypponen, and indeed our own David Harley, and I’ve nothing to add to that. You see – we were using Lotus Notes (~shudder~) and not one single system got infected – although we did get a tremendous amount of email, which very quickly got blocked once we knew the attachment name. No, I remember the Loveletter for what happened 10 years ago TODAY, the 5th of May. And, it is a tale I felt worth sharing, about how even good information about one situation is not necessarily applicable across the board.

Although they were not directly under my responsibility, my team had involvement with the IT systems of all the schools across Dorset, and while none of the systems we were responsible for were affected by Loveletter, this was not true of other systems within the schools, which were under supervision of the school’s own IT personnel. On the morning of the 5th of May, I sent out a message to everyone on our network to the effect that “Our network was not affected by the VBS/Loveletter worm, and no damage resulted from any mails that were opened within our network, but we request that you remain vigilant and avoid opening attachments that are not work related. We also suggest that you install an Anti-virus product at home, and ensure that any mails with the subject “ILOVEYOU” are deleted without being opened” This was the very last time I ever sent out such a message, not because it was incorrect, but because the information ended up being spread outside of our organisation – particularly in schools, where I’m sure people felt they were being helpful by forwarding my email – at which point I got several very angry phonecalls and emails abusing me for my lack of intelligence. The reason? The information was only true of our organisation, and those whose networks DID end up getting affected (Loveletter also deleted .jpg/jpeg images) were angry that I so downplayed the risks of the worm while they were watching it eat through all the images on their servers and workstations. In fact, many of the schools were running Microsoft Exchange and Outlook, and once their systems were infected, many pupils lost work.

This highlights the fact that information is often specific, it isn’t necessarily relevant to all situations. Think of it like fire extinguishers; they have specific uses on specific types of fires – don’t go spraying a water extinguisher onto an electrical or fat fire, you will get burned.

User education is often very difficult, and one of the reasons it is so is that there are so many variables, so many different ways that things can go wrong. In a way the Loveletter worm was one of the first Phishing attacks – it combined clever social engineering with malicious code to steal passwords. David Harley and I have written fairly extensively on Phishing, including examining whether the sort of ‘anti-phishing’ quizzes we’ve seen on some security sites are actually of any use. As far as I’m concerned, the jury is still out – there’s far too little common sense, too much irrelevant information, and it takes (literally) a lifetime to become a security expert; you can’t expect people to learn in five minutes.

As David mentioned yesterday, AVIEN was formed out of the need for non-vendors working in the AV industry to get fast and accurate information about spreading threats – I was glad to find that the instances where such information got so wildly misconstrued as in my Loveletter incident were few and far between. AVIEN also has its 10th birthday this year – more of that later in the year.

As an aside, I later applied for a job at one of the schools that had been affected, imagine how my heart sank when my interviewer turned out to be one of the people who had written me an angry email…no, I didn’t get the job! Anyway, it’s all water under the bridge, and since it is the 5th of May, my greetings to all my Mexican/Southern Californian friends, who will no doubt be regretting their today’s activities tomorrow morning.

Andrew Lee CISSP
AVIEN CEO / CTO K7 Computing

Changing Passwords: Should You Pass On It?

I’m seeing a lot of traffic about a story in the Boston Globe and taken up elsewhere suggesting that changing passwords is “a waste of time”. Well, actually, the study by Cormac Herley doesn’t exactly say that, and I suggest that you read the actual study to see what it does say. It’s actually well worth reading and makes some excellent points, though it’s not a particularly new paper, and some of the points it makes are much older. 

Should you stop changing passwords? Well, you probably don’t have much choice, in general. You should certainly use strong passwords, where possible (some systems actively work against you in that respect, by only accepting limited password options). Randy Abrams and I wrote a paper for ESET last year that discussed some password strategies, and one of the points made there was: 

 “It’s sometimes useful to consider whether frequent changes are really necessary or desirable. After all, if you’re encouraging the use of good password selection and resistance to social engineering attacks, and making it difficult for an attacker to use unlimited login attempts, a good password should remain a safe password for quite a while.”

I don’t think that the “change passwords every thirty days” mantra has been as universally enthused over by security specialists as the Globe suggests. System administrators (not always the same thing as security specialists) do often enforce such measures, of course. But while I was working on some notes for a journalist today on social engineering, I came across this quote in a paper I presented at EICAR in 1998. (I’ll have to put that paper up somewhere: it’s actually not bad, and not particularly outdated.)

“Documented research into social engineering hasn’t kept pace with dialogue between practitioners, let alone with real-world threats. Of course password stealing is important, but it’s [also] important not to think of social engineering as being concerned exclusively with ways of saying “Open, sesame…..”

Even within this very limited area, there is scope for mistrusting received wisdom. No-one doubts the importance of secure passwords in most computing environments, though the efficacy of passwording as a long-term solution to user authentication could be the basis of a lively discussion. Still, that’s what most systems rely on. It’s accepted that frequent password changes make it harder for an intruder to guess a given user’s password. However, they also make it harder for the user to remember his/her password. He/she is thus encouraged to attempt subversive strategies such as:

  • changing a password by some easily guessed technique such as adding 1, 2, 3 etc. to the password they had before the latest enforced change.
  • changing a password several times in succession so that the password history expires, allowing them to revert to a previously held password.
  • using the same password on several systems and changing them all at the same time so as to cut down on the number of passwords they need to remember.
  • aides-memoire such as PostIts, notes in the purse, wallet or personal organizer, biro on the back of the wrist…..

How much data is there which ‘validates’ ‘known truths’ like “frequent password changes make it harder for an intruder to guess a given user’s password”? Do we need to examine such ‘received wisdom more closely?”

Nor do I claim that those thoughts were particularly original: luminaries like Gene Spafford and Bruce Schneier have made similar observations. That doesn’t mean you should accept uncritically what they, or I, say. But it’s always worth wondering if received wisdom is really wise.

And as Neil Rubenking points out, an attacker isn’t going to waste time on trying to crack your password with brute force if he can trick you into telling it to him, or into running a keylogger. Which takes me right back to that social engineering paper… [Update: now available at http://smallbluegreenblog.wordpress.com/2010/04/16/re-floating-the-titanic-social-engineering-paper/]

AVIEN Chief Operations Officer
ESET Research Fellow & Director of Malware Intelligence
Mac Virus
Small Blue-Green World

Also blogging at:

Privacy, AVG, Facebook, Uncle Roger Thompson and all

My last post (https://avien.net/blog/?p=209) on Roger Thompson’s article about privacy concerns, “public” information and so on raised some interesting discussion.

Ironically (or perhaps appropriately) a lot of it was on Facebook.

I carried on the theme on the ESET blog, if you’re interested. “Your Data and Your Credit Card”, at:


Note that due to a couple of system crashes, a link to Allan Dyer’s excellent article disappeared in the first published version, but is fixed now:


Chief Operations Officer, AVIEN
Director of Malware Intelligence, ESET

Also blogging at:

Mac Whacks Back

It sometimes seems like I’ve spent the last twenty years trying to persuade Mac users that using a system named after a fruit doesn’t mean that there are no snakes in Eden or that angels will protect you from all harm.

Not, perhaps, completely in vain, but apparently many of the old Mac evangelist mindsets continue to prevail, irrespective of the true nature of the threatscape. (Macs don’t get viruses, Trojans don’t matter, there are no Mac vulnerabilities and if there were they’d be fixed immediately, social engineering is irrelevant, Microsoft Bad/Apple Good, blah….) There is a polite but nonetheless naive article that more than hints at this mindset here:


Thanks, however, to Kurt Wismer for reassuring me that Mac security is not just my own personal crusade:


I have a feeling I’m not done with this issue. And just to be clear: for most of those 20 years I was working for customers, not for vendors…

Chief Operations Officer, AVIEN
Director of Malware Intelligence, ESET

Also blogging at: