Security Blog

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 :-

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;
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

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 :-

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).
Impersonal salutations (“Dear Friend”) although personally addressed email isn’t a guarantee.
Offers to good to be true – when was the last time you won a prize in a competition you didn’t enter?
Strange wording. Either unnaturally good English or ridiculously bad English. Particularly from people you know or have corresponded with before.
“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 Phishing | Comments Off

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 Encrypted ZIP, Malware, ZIP | Comments Off

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

Cyber Essentials is changing – we have 10 months to adapt

Posted on 2022-02-03 by robbie

The Government approved Cyber Essentials scheme includes five technical controls that help protect organisations from the majority of cyber attacks. A team of experts review the scheme at regular intervals to ensure it stays effective in the ever-evolving threat landscape.

The scheme was introduced by the UK Government in 2014 as a way to help make the UK the safest place to do business. On January 24th 2022, some of the technical control requirements will change in line with recommended security updates. The evolution of Cyber Essentials allows UK businesses to continue raising the bar for their cyber security.

WHAT ARE THE CHANGES?
HOME WORKING DEVICES ARE IN SCOPE, BUT MOST HOME ROUTERS ARE NOT.
Anyone working from home for any amount of time is classified as a ‘home worker’. The devices that home workers use to access organisational information, whether they are owned by the organisation or the user, are in scope for Cyber Essentials.

Home routers that are provided by Internet Service Providers or by the home worker are now out of scope and the Cyber Essentials firewall controls are now transferred to the home worker’s device (computer, laptop, tablet and/or phone). However, a router supplied by the applicant company is in scope and must have the Cyber Essentials controls applied to it.

The use of a corporate (single tunnel) Virtual Private Network (VPN) transfers the boundary to the corporate firewall or virtual cloud firewall.

ALL CLOUD SERVICES ARE IN SCOPE
Cloud services are to be fully integrated into the scheme.

If an organisation’s data or services are hosted on cloud services, then the organisation is responsible for ensuring that all the Cyber Essentials controls are implemented. Definitions of cloud services have been added for Infrastructure as a Service, Platform as a Service and Software as a Service. Whether the cloud service provider or the user implements the control, depends on the type of cloud service.

WHY?
People commonly assume that cloud services are secure out of the box, but this is not the case. It is necessary for users to take responsibility for the services they use and spend time reading up and checking their cloud services and applying the Cyber Essentials controls where possible. Previously, Platform as a Service (PaaS) and Software as a Service (SaaS) were not in scope for Cyber Essentials, but the new requirements now insist that organisations take responsibility for user access control and the secure configuration of their services which would include securely managing access to the different administration accounts and blocking accounts that they do not need. Where the cloud service is in charge of implementing one or more of the controls ( eg security update management or anti-malware), the applicant organisation has the responsibility to seek evidence that this is done to the required standard.

MULTI FACTOR AUTHENTICATION MUST BE USED FOR ACCESS TO CLOUD SERVICES
As well as providing extra protection for passwords that are not protected by other technical controls, multi factor authentication should always be used to provide additional protection to administrator accounts and accounts when connecting to cloud services.

The password element of the multi-factor authentication approach must have a password length of at least 8 characters with no maximum length restrictions.

WHY?
There has been an increasing number of attacks on cloud services, using techniques to steal users passwords to access their accounts.

Multi-factor Authentication requires the user to have two or more types of credentials before being able to access an account. There are four types of additional factor that may be considered:

A managed enterprise device
An app on a trusted device
A physically separate token
A known or trusted account
THIN CLIENTS ARE IN SCOPE WHEN THEY CONNECT TO ORGANISATIONAL INFORMATION OR SERVICES
A thin client is a ‘dumb terminal’ that gives you access to a remote desktop. It doesn’t hold much data, but it can connect to the internet.

ALL SERVERS INCLUDING VIRTUAL SERVERS ON A SUB-SET OR A WHOLE ORGANISATION ASSESSMENT ARE IN SCOPE
Servers are specific devices that provide organisational data or services to other devices as part of the business of the applicant.

DEFINITION OF A ‘SUB-SET’ AND ITS IMPACT ON SCOPE
A sub-set is defined as a part of the organisation whose network is segregated from the rest of the organisation by a firewall or VLAN. A sub-set can be used to define what is in scope or what is out of scope of Cyber Essentials. Use of individual firewall rules per device are no longer acceptable.

DEFINITION OF ‘LICENSED AND SUPPORTED’
Licensed and supported software is software that you have a legal right to use and that a vendor has committed to support by providing regular patches or updates. The vendor must provide the future date when they will stop providing updates. The vendor does not have to be the original creator of the software, but they must have the ability to modify the original software to create updates.

ALL SMART PHONES AND TABLETS CONNECTING TO ORGANISATIONAL DATA AND SERVICES ARE CONFIRMED IN SCOPE WHEN CONNECTING TO CORPORATE NETWORK OR MOBILE INTERNET SUCH AS 4G AND 5G.
However, mobile or remote devices used only for voice calls, text messages or multi-factor authentication applications are out of scope.

DEVICE LOCKING
Biometrics or a minimum password or pin length of 6 characters must be used to unlock a device.

PASSWORD-BASED AND MULTI-FACTOR AUTHENTICATION REQUIREMENTS
When using passwords, one of the following protections should be used to protect against brute-force password guessing:

Using multi-factor authentication
Throttling the rate of unsuccessful or guessed attempts.
Locking accounts after no more than 10 unsuccessful attempts.
Technical controls are used to manage the quality of passwords. This will include one of the following:

Using multi-factor authentication in conjunction with a password of at least 8 characters, with no maximum length restrictions.
A minimum password length of at least 12 characters, with no maximum length restrictions.
A minimum password length of at least 8 characters, with no maximum length restrictions and use automatic blocking of common passwords using a deny list
People are supported to choose unique passwords for their work accounts.

New guidance has been created on how to form passwords. It is now recommended that three random words are used to create a password that is long, difficult to guess and unique.

There is an established process to change passwords promptly if the applicant knows or suspects the password or account has been compromised.

ACCOUNT SEPARATION
Use separate accounts to perform administrative activities only (no emailing, web browsing or other standard user activities that may expose administrative privileges to avoidable risks)

THE SCOPE OF AN ORGANISATION MUST INCLUDE END-USER DEVICES
WHY?
If an organisation certifies their server systems only, they ignore the threats that come from their administrators who administered those server systems. The change to this requirement closes the loop-hole where organisations were able to certify their company without including any end user devices. Cyber Essentials must now include end point devices.

ALL HIGH AND CRITICAL UPDATES MUST BE APPLIED WITHIN 14 DAYS AND REMOVE UNSUPPORTED SOFTWARE
All software on in scope devices must be:

Licensed and supported
Removed from devices when it becomes un-supported or removed from scope by using a defined ‘sub-set’ that prevents all traffic to/from the internet.
Have automatic updates enabled where possible
Updated, including applying any manual configuration changes required to make the update effective, within 14 days of an update being released, where:
– The update fixes vulnerabilities described by the vendor as ‘critical’ or ‘high risk’

– The update addresses vulnerabilities with a CVSS v3 score of 7 or above

– There are no details of the level of vulnerabilities the update fixes provide by the vendor

WHY?
Previously, there was a set criteria that the vulnerabilities which had to be applied had to meet which were laid out in the requirements. These criteria have now been dropped and organisations need to apply all high and critical updates on all their systems. This is raising the bar because organisations can no longer be selective about which patches they apply and leave themselves weak and vulnerable.The reason for these changes can be illustrated by a high profile example this year. A vulnerability in the Microsoft Exchange System came out very publicly and was reported by numerous news outlets. That attack went from being a complex state actor attack to a commodity attack within seven days. It was commoditized into a ransomware attack only 12 hours later. This proves that a high complexity attack can be commoditized in hours and for this reason, all high and critical updates, need to be applied within 14 days, both for Cyber Essentials and Cyber Essentials Plus.

GUIDANCE ON BACKING UP
Backing up your data is not a technical requirement of Cyber Essentials, however there is now guidance on backing up important data and implementing an appropriate backup solution is highly recommended.

TWO ADDITIONAL TESTS HAVE BEEN ADDED TO THE CYBER ESSENTIALS PLUS AUDIT
Test to confirm account separation between user and administration accounts

Test to confirm MFA is required for access to cloud services.

HOW THE CHANGES WILL WORK
There will be a grace period of one year to allow organisations to make the changes for the following requirements:

MFA FOR CLOUD SERVICES
The requirement will apply for administrator accounts from January 2022

The MFA for users requirement will be marked for compliance from January 2023

THIN CLIENTS
Thin Clients need to be supported and receiving security updates, the requirement will be marked for compliance from January 2023

The new question will be for information only for first 12 months.

SECURITY UPDATE MANAGEMENT
Unsupported software remove from scope will be marked for compliance from January 2023

Posted in Uncategorized | Comments Off

On Receiving USB Memory Sticks In The Post

Posted on 2022-01-17 by mike

A warning has been made about US businesses receiving “bad” USB memory sticks in the post. Although not a new form of attack, what is new is that the USB sticks may contain mass ransomware malware.

If you receive items in the post, be especially wary of USB memory sticks – if the stick is unexpected, it comes from a sender you haven’t received anything from before, or if there are other reasons to suspect it, pass it along to IS for inspection.

That’s a genuine “bad USB” stick from my collection of tools; real “bad USB” sticks won’t be quite as obvious.

Whilst a USB memory stick is just a memory stick, an attacker can build (or buy) something that looks like a memory stick but can be programmed to act as almost any kind of USB device – a keyboard, a mouse, or something else.

A keyboard is quite common because an attacker can insert fake keystrokes that will install malware and then take over full control of the system you are using.

Posted in Uncategorized | Comments Off

Cyber Essentials v3.0

Posted on 2021-11-30 by robbie

In the January 2022, the NCSC will introduce an updated set of requirements for the Cyber Essentials scheme (v3.0). This update is the biggest overhaul of the scheme’s technical controls since it was launched in 2014 and is in response to the evolving cyber security challenges that organisations now face.

The way we work has changed dramatically over a short period of time. The speed of the digital transformation and the adoption of cloud services are driving factors here, as well as the move to home and hybrid working, accelerated by the COVID-19 pandemic, which is now routine for many people.

The refresh of Cyber Essentials reflects these changes and also signals a more regular review of the scheme’s technical controls.

The University passed the annual Cyber Essentials – Plus recertification on 29 November 2021. In late November 2022, we will have to be ready to re-certify to v3.0. An assessment of the impact of any changes is underway and plans to adapt our working practices will follow.

Please contact Rob Walker (robbie.walker@port.ac.uk) if you have any questions.

Posted in Uncategorized | Comments Off

The “Secret” BCC Email Header

Posted on 2021-09-28 by mike

You want to send an email to a long list of people; perhaps that list should remain private, or perhaps you just want to avoid the inconvenience of people seeing a huge “To” field with tons of other addresses in. What do you do?

Use the “Bcc” field.

When composing a new message in Google Mail :-

Click on the little “Bcc” at the top right :-

The window changes to show the “Bcc” header into which you can enter addresses to send the email to – which won’t be visible to those receiving the mail.

“Bcc” is short for “blind carbon copy” a reference to an ancient office technology that most of us are too young to remember (even me!). But it can be regarded as the same as “To” except that addresses listed within it are not sent to the recipient.

Why is this important?

For a start, it is a lot neater for those reading the message without seeing a whole mess of additional recipient addresses.

Secondly (and far more importantly), if the recipient addresses are private, showing those addresses in an email is a security breach. Whilst not generally as serious, it can lead to news such as the recent leak of the email addresses of Afghanistan interpreters.

If you do not use the Google Mail interface, you should still be able to use the “Bcc” header when composing messages although how will vary from client to client.

Posted in Email, General | Comments Off

Firewall Blocking Essentials?

Posted on 2021-09-15 by mike

Due to a certain episode around Easter this year, a number of changes were made to the firewall security policy to make it more secure. Since then a great deal of work has gone into identifying web-based applications that are in use and making sure they’re allowed through the firewall.

But in all likelihood, we’ve missed a few.

So it makes sense to test everything that you use for teaching (or anything else) to see if it works properly. If it doesn’t :-

Connect to the VPN (whether you are at home or on campus).
Try again
Raise a servicedesk job requesting that “it” be allowed. To make it easier the following would be helpful :-
1. What username you logged into the VPN with.
2. Around what date and time did you try – the more accurate and precise you can make this, the better.
3. A description of the application and why it is required.
4. If you received an error, what was the text of the error message?

Don’t worry if it’s just a “nice to have” application – whilst there are security reasons for saying no, that is relatively rare and we’re not inclined to say no to something that looks like entertainment (for example).

Posted in Firewall | Comments Off

GlobalProtect Installation for MFA VPN

Posted on 2021-05-05 by mike

This is a technical guide to some methods of installing/fixing the GlobalProtect client in the short term whilst ongoing conversations with the relevant vendors is taking place.

Make sure you are using an up to date version of the client; the latest officially deployed version of which can be downloaded from https://staff.vpn.port.ac.uk/ or https://student.vpn.port.ac.uk/. It would be wise to completely remove older clients from the machine.
Make sure that the machine is running a supported operating system.

Windows Installation

This requires a command-line installation with a switch to turn on the “default browser” option :-

msiexec.exe /i GlobalProtect.msi DEFAULTBROWSER=YES

Where “GlobalProtect.msi” is the file you have copied onto the client machine.

Mac Installation

Installation on a Mac is done in the usual way but before the VPN client is run, a terminal command needs to be run :-

sudo defaults write /Library/Preferences/com.paloaltonetworks.GlobalProtect.settings.plist '{"Palo Alto Networks" ={GlobalProtect={Settings={default-browser=yes;};};};}'

That’s all on one line.

Switching Browser

At least one report suggests changing the default browser on the client machine to an alternate browser – specifically from Chrome to Firefox.

Posted in Technical, VPN | Comments Off

Spam: Mail Quotas and Bitcoin

Posted on 2021-02-22 by mike

Recently we have become aware of an issue in relation to one of our cloud service providers which is weakening one of our email security measures – specifically the mechanism put in place to make it harder to impersonate UoP senders (i.e. any @port.ac.uk email address). This has allowed a recent increase in the amount of spam being received.

As of late in the afternoon of the 24th February, the cloud vendor has fixed the issue so there relevant spams should stop arriving. Leaving just ordinary spams!

We are in contact with the vendor to resolve this issue, but in the meantime you very well may receive spams with a sender address (“From”) of something@port.ac.uk.

Two quite common varieties of spam that are cropping up are mentioning mail quotas (“your mail quota is exceeded”) and bitcoins (“pay us bitcoin or we’ll leak your secrets”).

In relation to the mail quota spams :-

This example may not reflect the appearance of spams you receive.

We do not have mail quotas; anyone offering to increase your mail quota is offering to do the impossible … or more likely ask you for your password so they can use it nefariously.
If you “hover” (move the mouse pointer to where the clickable link is, but don’t click it), you can see where the link really takes you too at the bottom of the browser window. In the case of this spam, it will say something like https://port.ac.uk/mail-quota/ but will in fact take you somewhere else.

This is a standard phishing spam email – the link will take you to a page that looks like a login window and you will be prompted for your password. Don’t fill it in!

In the case of the bitcoin extortion spams, the main characteristic is that they say something that amounts to “send us bitcoin or we’ll leak all your secrets”. Sometimes they will claim to have broken into your account; sometimes they will claim to have recorded you indulging in activities that you won’t want others to know.

Whilst this could be alarming, it is exceptionally unlikely to be the truth. Extortion spams are widespread and known to have no truth behind them; although the latest ones don’t appear to be “sextortion”, it remains a possibility.

If you are wondering what “bitcoin” is, a link to the Wikipedia article can be found earlier in this article, but in summary it is a “crypto-currency” which is form of money without a backing government/central bank implemented using cryptographic mechanisms. Criminals appear to like it because they (falsely) believe it to be anonymous.

Whilst this is an ongoing situation with a special wrinkle, the advice is still pretty standard :-

If it sounds too good to be true, it probably is.
Does the email “ring right”? If it came from an @port.ac.uk address :-
1. Does it look like it was composed in Gmail
2. Do you normally receive emails from that sender?
3. Is the writing standard what you would expect?
Before you click on a link, check (by “hovering”) if that link takes you to where you expect.
If you click on the link, does the page appear to be in the usual UoP style? Most of our authentication pages go through the same “identity provider” and although there are two main ones with different appearances, they do have a standard “look”.

Because of the current issue (which we expect to resolve in a day or two), be wary of emails from @port.ac.uk addresses that you haven’t corresponded with before.

Posted in Active Attacks, Email | Tagged Bitcoin, Mail Quota, Phishing, Spam | Comments Off

Detecting Suspicious Emails

The Raw View

The Headers

The Body

Final Assessment

An Email With An Encrypted ZIP Attachment?

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

Cyber Essentials is changing – we have 10 months to adapt

On Receiving USB Memory Sticks In The Post

Cyber Essentials v3.0

The “Secret” BCC Email Header

Firewall Blocking Essentials?

GlobalProtect Installation for MFA VPN

Windows Installation

Mac Installation

Switching Browser

Spam: Mail Quotas and Bitcoin

Recent Posts

Recent Comments

Archives

Categories

Meta