Does That Suspicious Email Contain A QR Code?

Posted on 2023-09-21 by mike

In some cases, suspicious emails might contain QR codes to take you to a web site for further action :-

For example :-

From: UoP Helpdesk <helpdesk.port.ac.uk@gmail.com>
Subject: Mail Quota

Dear User,

Your email quota is close to being used up. To enable additional quote, please fill out the form found on the link below :-

In general, QR codes can contain web site addresses, but because they are encoded, it makes it harder for you to read them (so you can’t think “Hey! That looks odd”) and harder for security software to process them.

Anywhere where they appear where an ordinary link would serve just as useful service, should add some suspicion. Painted on the side of the building is another matter.

For example, in the email above :-

  1. There is no “To” and your address doesn’t appear in it.
  2. The “From” address is wrong both in terms of the “name” (we don’t have a “Helpdesk”, we have a “Servicedesk”) and in the form of the address (helpdesk.port.ac.uk@gmail.com – look where the “@” is, and the presence of “port.ac.uk” as part of the bit before the “@”).
  3. The salutation (“Dear User,”) is generic and not specific. Legitimate emails can be generic but it’s still a suspicion point to add to the overall score.
  4. The “Your email quota is close to being used up” adds a sense of urgency to take the action before bad consequences.
  5. And lastly using a QR code instead of a web site address so you can’t inspect the address adds more suspicion.

Posted in Active Attacks, Email | Tagged , | Leave a comment

Encrypting Apple Devices

Posted on 2023-09-20 by superadmin

So to begin with, why encrypt?

To keep your data private in the event of other people obtaining access to your device. In some cases that is in your own interest (such as for personal devices not used for work) and in some cases the university wants you to!

And in the future, you may well find your access to university services becomes limited if you do not.

And it is so easy to do.

Encrypting iPhones and iPads

These instructions were prepared using an iPad, but they should apply well to an iPhone as well.

First of all, select the Settings app :-

One that is running, select “Touch ID and Passcode” which is found on the left-hand side :-

And then select “Turn Passcode On” (circled in some sort of pink-like colour).

This will take you through the process of setting a six-digit passcode (which you will have to enter twice), and just as a precaution it also requires you to login to iCloud.

Once it is set, that should be all that needs doing. Everything on your iThingie is now encrypted.

On macOS Laptops

Turning on encryption for a laptop with macOS running on it is only marginally more complicated. First of all, visit the Settings app (which has much the same cog-like icon as above), and select “Privacy and Security” down the left-hand side.

Once there, you may have to scroll down to see it, but the “FileVault” section is what you need. In my case, it is already turned on (and I’m not turning it off for this), but click on the “Turn On” button and it will take you through the process.

Oh! And if you have a red circled number next to your “Software Update Available” menu item, do an update too. I’m only waiting until the end of the working day before I kick mine off.

Posted in General | Tagged , , , , , | Leave a comment

Do You Know How Many Cyber Attacks We See?

Posted on 2023-09-08 by mike

One of the things that most people are probably not aware of is just how many attacks the university sees on a daily basis. For example, yesterday (a middling day in September) the firewall identified and blocked 100,839 attacks. Now most of those attacks were not especially serious, but many were.

One of the many things that the LIS Cyber Operations team does, is to identify the most serious of those attacks, and block them for 3 months, a year, or permanently depending on whether this is the first attack, the second, or the third.

As you can see, every month we block a very rough average of 1,200 attackers. Actually we can add to those figures a few hundred more attacker addresses that are made known to use as “threat intelligence” – attacks that may not have attacked us, but have attacked others.

In case anyone is worrying about blocking legitimate sites, that very rarely happens – not only do legitimate sites rarely perform attacks, but our block list is currently 7,357 entries long. This is approximately 0.00017% of the Internet (or to be more precise the technical maximum of IPv4 addresses on the Internet; many of which are reserved).

Not much more to say about it – criminals are going to crime. And no these events aren’t organised by spotty teenagers in basements; it’s organised crime.

Posted in Active Attacks, Malware | Tagged , , | Comments Off on Do You Know How Many Cyber Attacks We See?

I’m gonna stop you little phishie….

Posted on 2023-05-25 by robbie

Some organisations put a lot of effort into training their staff to detect and evade phishing attacks. Some even punish them if they slip up. Here’s some thinking from the National Cyber Security Centre…

https://www.ncsc.gov.uk/blog-post/im-gonna-stop-you-little-phishie

Posted in Uncategorized | Comments Off on I’m gonna stop you little phishie….

LastPass Leak: What You Need to Do to Protect Your Passwords (CNET article)

Posted on 2023-01-17 by robbie

For anyone using LastPass…
In late December, LastPass announced that a security incident had allowed an unauthorised party to steal customer account information and vault data.

What should LastPass subscribers do?
Unfortunately, LastPass have not revealed how many users were affected by the breach, and LastPass didn’t respond to CNET’s request for additional comment on the breach.
If you’re a LastPass subscriber, you need to operate under the assumption that your user and vault data are in the hands of an unauthorised party with malicious intentions. Though the most sensitive data is encrypted, the problem is that the threat actor can run “brute force” attacks on those stolen local files. LastPass estimates it would take “millions of years” to guess your master password — if you’ve followed its best practices.

If you just want total peace of mind — you’ll need to spend time and effort changing your individual passwords.

Here’s what you need to do right now if you’re a LastPass subscriber:

1. Find a new password manager. Given LastPass’ history with security incidents and considering the severity of this latest breach, now’s a better time than ever to seek an alternative.

2. Change your most important site-level passwords immediately. This includes passwords for anything like online banking, financial records, internal company logins and medical information. Make sure these new passwords are strong and unique.

3. Change every single one of your other online passwords. It’s a good idea to change your passwords in order of importance here too. Start with changing the passwords to accounts like email and social media profiles, then you can start moving backward to other accounts that may not be as critical.

4. Enable two-factor authentication wherever possible. Once you’ve changed your passwords, make sure to enable 2FA on any online account that offers it. This will give you an added layer of protection by alerting you and requiring you to authorize each login attempt. That means even if someone ends up obtaining your new password, they shouldn’t be able to gain access to a given site without your secondary authenticating device (typically your phone).

5. Change your master password. Though this doesn’t change the threat level to the stolen vaults, it’s still prudent to help mitigate the threats of any potential future attack — that is, if you decide you want to stay with LastPass.

Ref: https://www.cnet.com/tech/services-and-software/lastpass-leak-what-you-need-to-do-to-protect-your-passwords/

Posted in Uncategorized | Comments Off on LastPass Leak: What You Need to Do to Protect Your Passwords (CNET article)

Locating Java Installs

Posted on 2022-09-14 by mike

In some cases vulnerability scanners will tell you that there is a vulnerable version of Java installed but not tell you where it is. This is a short post on solving that problem – for Linux machines.

Run the following code :-

for j in $(find / -type f -executable -name java)
do
echo $j, $($j -version 2>&1 |head -n 1)
done 2> /dev/null

And you will get a list of pathnames to java binaries with the version shown after the comma :-

/opt/java_splunk/jdk1.8.0_212/bin/java, java version "1.8.0_212"
/opt/java_splunk/jdk1.8.0_212/jre/bin/java, java version "1.8.0_212"
Posted in General, Technical | Comments Off on Locating Java Installs

Phishing Attacks Against Academics with an Interest in Russia/Ukraine

Posted on 2022-08-18 by mike

We have been alerted to the activities of a politically-motivated phishing “crew” targeting (amongst others) the Higher Education sector with particular reference to academics with interests in Russia and Ukraine.

The attacks look to be targeted to specific individuals with reconnaissance being carried out in advance using social media (specifically LinkedIn) or other public information (OSINT). The attacker will then create email accounts at consumer email providers with email addresses configured to resemble known contacts.

The attacker will then contact the target very often with an initially benign email before mentioning a missing attachment (with a topic of interest). A reply will result in a “weaponized” email being sent which may consist of the following forms :-

  1. A website link to malicious content.
  2. An attached PDF with a website link to malicious content.
  3. A link to a Microsoft OneDrive share containing a PDF with a website link to malicious content.

The website link is usually a link to a credentials acquisition site – i.e. it will capture usernames and passwords. And then will show some innocuous (and relevant) information.

To defend against such attacks :-

  1. If you are working, turn on the GlobalProtect VPN. There are some additional defences against phishing when you go through the University firewall (which includes the VPN).
  2. Be suspicious of new contacts – does the email address match previously published email addresses? Does it look like a personal address rather than an academic address?
  3. Be suspicious of old contacts who exhibit a change – are they using their usual email address? Has the tone of their language changed?

Posted in Active Attacks, Email | Tagged , , | Comments Off on Phishing Attacks Against Academics with an Interest in Russia/Ukraine

Detecting Suspicious Emails

Posted on 2022-08-17 by mike

This blog post is going to be somewhat longer and more technical than usual. It is intended as documentation for the use of IS staff, but may be more widely useful (at least in parts). To start with emails come in two parts – a header section, and one or more body parts.

You can do some analysis of the body of the email, but what can be done there is rather limited and has been covered before. However to go for a deep dive into the technicalities we need to have access to the full headers of the email.

Another thing to remember is that there is no guarantees on any of the signs in the headers (or the body) of faked/malicious emails; it’s a game of probabilities – if you get one or two indications that things are a bit “off” then it could well be legitimate; if you get many signs then it is most likely not legitimate.

The Raw View

This is a legitimate email … and the headers are rather scary :-

Delivered-To: someone@port.ac.uk
Received: by 2002:a4a:80c4:0:0:0:0:0 with SMTP id a4csp5624563oog;
        Thu, 7 Jul 2022 07:01:05 -0700 (PDT)
X-Google-Smtp-Source: AGRyM1txkbSraTKe9LYdHuciBI/kNXNlcAgkNZT9pxAwqYxVJeD0ZhOER+04vWiJl4T99ZxoHX7b
X-Received: by 2002:a17:90b:1b41:b0:1ec:747c:5d1 with SMTP id nv1-20020a17090b1b4100b001ec747c05d1mr5435707pjb.213.1657202464930;
        Thu, 07 Jul 2022 07:01:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1657202464; cv=none;
        d=google.com; s=arc-20160816;
        b=tMx01iiG936FOOZW5sN4b6L7hQYIzEt6DinePrQYAeefM9UQEGLxQyKYSPZ5KSFfjx
         fPwykDUtXaKnEQUiReiI52M3vhBAVmRl1DTwX+xJjdp17TkDshWioq3vsKtowSBt7eju
         ztnU7xyS2g2XsRkp0L8NGtA6kIW1LZvUUD6OfN3dsFOZMRFmLXjMvWOCn+A2k87mon2z
         rEMXX+zU+g4j5/7R9dl9qb+v5MkXylcgKVrXx3/akTDVbfk8BADejiM20FXGN4XDqrOA
         z6azs/14qkvvZiH1vhrVhIMgbzy8si864lirE2J2YKcgWK5MXcy3zrY2t4IO0HMbONZK
         tt8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:list-unsubscribe:reply-to:mime-version:date:to:subject
         :message-id:from:dkim-signature;
        bh=oMI0usDG210zNBNaRijk6ss9HEYFI5LreIegG7NV5VM=;
        b=fF/FBqI+dHHhJwXP73exu7pVALIgXYesFYKQMn9u2tmT27K69Ok53dqwQ9a0NOeIMO
         n0Eke4dfIBELZLB7FahLAL8QoFFysPjAGNduqfE//K18+86n7Wg/jMbBr4BJGL9ltloH
         f5IzlIz2HOp12XCcyAy+WVsUhDDy8zuInUlyUrIF+5mnf9NPPVCaIsHI7N9MLXkgbsZX
         UpS6x5GYJOhFlFe+QvR7/pfqhbP0ciKBrPN49TVSJF2EeH9/SewYuJlh5dZoZpsydD8L
         AxiqPBH+3tqdnMaaOnQSZ26KBrsnCCBFAaZ8re51JwVdO8p3C/bGWOXraExrpH1WP+JY
         5NFQ==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@i.drop.com header.s=scph0618 header.b=fZScuZfV;
       spf=pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) smtp.mailfrom=bounce-1657185485459.475823232258128637708151@i.drop.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=drop.com
Return-Path: <bounce-1657185485459.475823232258128637708151@i.drop.com>
Received: from mta-215-244.sparkpostmail.com (mta-215-244.sparkpostmail.com. [147.253.215.244])
        by mx.google.com with ESMTPS id s144-20020a632c96000000b0041160e45f31si305281pgs.97.2022.07.07.07.01.04
        for <someone@port.ac.uk>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 07:01:04 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) client-ip=147.253.215.244;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@i.drop.com header.s=scph0618 header.b=fZScuZfV;
       spf=pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) smtp.mailfrom=bounce-1657185485459.475823232258128637708151@i.drop.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=drop.com
X-MSFBL: 6Li1OAD6jdxrnkaoy/Hp4l4bxHUhsaA7/9w1iFnYAa4=|eyJjdXN0b21lcl9pZCI
 6IjEiLCJyIjoibWlrZS5tZXJlZGl0aEBwb3J0LmFjLnVrIiwic3ViYWNjb3VudF9
 pZCI6IjAiLCJ0ZW5hbnRfaWQiOiJtYXNzZHJvcCIsIm1lc3NhZ2VfaWQiOiI2Mjk
 4ZjdhNGM2NjJlNWRjNTBlZSJ9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i.drop.com;
 s=scph0618; t=1657185527; i=@i.drop.com;
 bh=oMI0usDG210zNBNaRijk6ss9HEYFI5LreIegG7NV5VM=;
 h=From:Message-ID:Subject:To:Date:Content-Type:From:To:Cc:Subject;
 b=fZScuZfVPkO10/ytHgvYkX2WAWsxyqr5QejjTPzYZAwCFcUlGH014uocHgPrgS05I
  KxUT2cm2BPQSd1ikShdeswe8MptNWMkE4fqIna17w3+CDinB5hRJ426ojqUHORMjB7
  R0jADRfBZF+GDuRCMSKBOxKTCTEgPZzj/H+ddS0M=
From: "Drop" <info@i.drop.com>
Message-ID: <05.EE.19583.7F4A6C26@gy.mta2vrest.cc.prd.sparkpost>
Subject: Drop + MiTo Serenity Desk Mat, Phangkey Amaterasu Desk Mat, Drop GMK White-on-Black Custom Keycap Set and more...
To: "Someone" <someone@port.ac.uk>
Date: Thu, 07 Jul 2022 09:18:09 +0000
Content-Type: multipart/alternative; boundary="_----cGGBgCxDlmJHT7JNSry5qA===_E0/C1-29399-27466C26"
MIME-Version: 1.0
Reply-To: support@drop.com
List-Unsubscribe: <mailto:unsubscribe@i.massdrop.com?subject=unsubscribe:ch4jzusTih96iuHiPvllEJD8RtThf9s8fddYQJW3G8Q~|eyAicmNwdF90byI6ICJtaWtlLm1lcmVkaXRoQHBvcnQuYWMudWsiLCAidGVuYW50X2lkIjogIm1hc3Nkcm9wIiwgImN1c3RvbWVyX2lkIjogIjEiLCAic3ViYWNjb3VudF9pZCI6ICIwIiwgIm1lc3NhZ2VfaWQiOiAiNjI5OGY3YTRjNjYyZTVkYzUwZWUiIH0~>
List-Id: <massdrop.1.0.sparkpostmail.com>

We’ll go through some of the more interesting parts of that shortly, but the key thing to remember is that the original sender (or any “hop” along the way) can insert anything it wants into those headers, so they cannot be trusted.

Or rather there are variable levels of trust.

The Headers

From: "Drop" <info@i.drop.com>

So the first thing to say is that the “From” header is likely to be the least trustworthy header in there. Whilst you probably can’t change where your emails “come from”, anyone using custom software (or crafting their own emails by hand) can put anything they like in there. So if it says “someone@port.ac.uk” there is no guarantee that it was really me that composed it (although there is some measures in place to make forging @port.ac.uk email addresses harder but not impossible).

One thing to look for are whether the two parts of the “From” header match or make some kind of sense – in this case we have “Drop” and <info@i.drop.com> which does match (in the loosest sense of the word). An example from a different email doesn’t look quite the same: “SleepConnection” <info@makeupfling.co> (taken from a real spam message).

Reply-To: support@drop.com

The next header to look at is the “Reply-To” header which may or may not be present – it effectively redirects replies to a different address. If the address included (support@drop.com) has a different domain (the bit after the “@”) then it becomes a bit more suspicious. 

To: "Someone" <someone@port.ac.uk>

And onto the “To” header (and to a certain extent the “Cc” header). This doesn’t necessarily contain your email address; nor is the absence particularly suspicious – there is in addition to the “CC” header (which also contains email addresses the email is to be delivered to), there is also an invisible “Bcc” header.

Legitimate email takes the email addresses from the “To”, “CC”, and “Bcc” headers, and adds those addresses to the “envelope” (which isn’t shown in the headers). It will also remove the “Bcc” header to preserve privacy.

Malicious emails populate the “envelope” without reference to the headers; which basically means that if the “To” field contains a name you do not recognise there is a slightly more suspicious. But if it contains your own email address that doesn’t make it trustworthy – it’s neutral.

Date: Thu, 07 Jul 2022 09:18:09 +0000

Probably not the most significant header to inspect, but there is no harm checking for impossible dates – either in the future (watch out for time zones) or in the past.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i.drop.com;
 s=scph0618; t=1657185527; i=@i.drop.com;
 bh=oMI0usDG210zNBNaRijk6ss9HEYFI5LreIegG7NV5VM=;
 h=From:Message-ID:Subject:To:Date:Content-Type:From:To:Cc:Subject;
 b=fZScuZfVPkO10/ytHgvYkX2WAWsxyqr5QejjTPzYZAwCFcUlGH014uocHgPrgS05I
  KxUT2cm2BPQSd1ikShdeswe8MptNWMkE4fqIna17w3+CDinB5hRJ426ojqUHORMjB7
  R0jADRfBZF+GDuRCMSKBOxKTCTEgPZzj/H+ddS0M=

The significance of this header becomes relevant later on … as it is, it is a claim that the listed headers and the body of the email message have been digitally signed. Of course it has to be verified which comes later …

Received-SPF: pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) client-ip=147.253.215.244;

This is quite similar to the DKIM signature in that it is a test of whether the email comes from a mail server that the associated mail domain designates as a legitimate source. 

Authentication-Results: mx.google.com;
       dkim=pass header.i=@i.drop.com header.s=scph0618 header.b=fZScuZfV;
       spf=pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) smtp.mailfrom=bounce-1657185485459.475823232258128637708151@i.drop.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=drop.com

Now this claims to be a header added by Google (mx.google.com) giving the results of an authentication test – in this case we can see that the DKIM test passed – so the previous DKIM signature has been verified, the SPF test has passed, and the DMARC policy has passed – so there are good grounds for the sender of the domain is genuine.

This doesn’t mean that the email is genuine; just that the sender domain is valid. 

Received: from mta-215-244.sparkpostmail.com (mta-215-244.sparkpostmail.com. [147.253.215.244])
        by mx.google.com with ESMTPS id s144-20020a632c96000000b0041160e45f31si305281pgs.97.2022.07.07.07.01.04
        for <someone@port.ac.uk>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 07:01:04 -0700 (PDT)

There’s quite a lot of information to be found in the “Received” headers – bearing in mind that headers can’t be totally trusted. In this example, the very first couple of lines claim that the message was received by mx.google.com (which looks legitimate) and was sent by mta-215-244.sparkpostmail.com.

The appearance of the hostname twice is because the first occurrence is what the sending mail server thinks it’s name is, and the second is Google’s (in this case) attempt at verification based on the network address. Matching is a good sign.

The Body

If you have read up to this point, you are probably already aware of the indications within the body of an email that make it look suspicious including but not limited to :-

  1. Links to sites labelled as one thing, but with the address of something else (i.e. looks like https://foo.com/ but actually goes to https://foo.com.bad.place).
  2. Impersonal salutations (“Dear Friend”) although personally addressed email isn’t a guarantee.
  3. Offers to good to be true – when was the last time you won a prize in a competition you didn’t enter?
  4. Strange wording. Either unnaturally good English or ridiculously bad English. Particularly from people you know or have corresponded with before.
  5. “Unusual” requests – especially requests to bypass standard procedures.

Final Assessment

As hinted at previously, an email may have suspicious indications but still be legitimate and an email may have no suspicious indications yet still be malicious. Determining which emails are legitimate and which are not, is not an easy thing to do – or it would be done automatically with total accuracy.

In fact a certain amount of illegitimate email is detected automatically and blocked; probably far more than we’re aware of. So we’re usually stuck determining the legitimacy of “edge cases”.

In assessing an email we look at the number of suspicious elements – if high enough we can judge it to be illegitimate. In areas of doubt, it is advised to verify the email contents “out of band” – with a phone call, checking with a colleague, or contact via an email address pulled out of a contacts database (and not the email).

Posted in Email, Malware | Tagged | Comments Off on Detecting Suspicious Emails

An Email With An Encrypted ZIP Attachment?

Posted on 2022-03-03 by mike

That’s suspicious!

At least it is if the password to decrypt the ZIP file is contained within the email – when you’re sending something secret you would send an encrypted ZIP file as an email and then send the password through some other means. Such as a phone call, or a text message.

If you get an email with an encrypted ZIP file with the password in the email, in all likelihood it is malware inside the attachment. There are plenty of email services that virus check attachments but they can’t make much headway with an encrypted archive containing the malware.

Posted in Active Attacks, Email | Tagged , , | Comments Off on An Email With An Encrypted ZIP Attachment?

Why foiling phishing attacks means much more than just punishing users for falling for them.

Posted on 2022-02-17 by robbie


Advice from the NCSC:

Some organisations put a lot of effort into training their staff to detect and evade phishing attacks. Some even punish them if they slip up.

It’s easy to see why the user has been identified as a central factor in phishing prevention – successful phishes after all depend on an attacker persuading a user to click on something they shouldn’t. So if bad guys can persuade users to click, it must be equally possible for us good guys to persuade users NOT to click. Right?

Wrong. It’s not a level playing field, and users can’t solve the phishing problem all by themselves. Trying to make your users invulnerable to phishing does nothing but waste your organisation’s time and money.

Some phishing emails are very competently executed to the extent that they are impossible to tell apart from genuine emails just by inspection. No amount of training, or punishment for getting it wrong, will change this. Furthermore, phishing attackers deliberately appeal to us emotionally. They say “Quick! Someone’s trying to steal your money! Come with me if you want to live.” Often we naturally respond to such appeals instinctively, without really thinking. Training tries only to develop our intellectual ability to spot phishes – it can’t stop us reacting to things designed to push our emotional buttons.

Furthermore, asking users to spot phishes means asking us to deliberately go against our normal working habits. Anti-phishing training teaches us to be suspicious of opening emails, clicking on links and opening attachments. But if we don’t do this, we can’t do our jobs. Most of us struggle to meet these two contradictory goals at the same time. The risk of attracting a sanction for falling for a phishing attack might mean we fear to open legitimate emails – which will have business costs. These costs are usually hard to see and measure – but they are there. We end up having to choose between the possibility of getting phished, or the certainty of harming our productivity. Many of us receive dozens of emails a day and must make these decisions every time, in a split-second, amid dozens of other pressures and distractions. At some point, we will inevitably make a bad call.

Rather than burdening users with impossible demands that leave them stuck between a rock and a hard place, we recommend that phishing is best tackled by implementing good technical defences and combining these with reasonable levels of user awareness, education and training. Setting up and maintaining your systems in accordance with our guidance will mean many phishing attacks are stopped before they do any harm, and the NCSC continues to develop and implement new anti-phishing measures that stop phishing emails getting to users’ inboxes in the first place.

It is worth telling users about common types of phishing attacks, particularly those that tend to be targeted at high-value users within organisations (a technique known as whaling).

And you should also encourage users (in a positive, blame-free manner) to report any emails or websites they are unsure about, even if they have already clicked.

However, trying to eradicate every single bad click is an unrealistic and harmful goal. As we’ve said elsewhere, users have a limited amount of time and effort to spend on security. Let’s make sure they put that effort in the places where it gets the best results.

Emma W
People-Centred Security Lead, Sociotechnical Security Group, NCSC

Posted in Uncategorized | Comments Off on Why foiling phishing attacks means much more than just punishing users for falling for them.