Phishing emails are one of the most common attempt to steal user’s personal or sensitive information. Cyber criminals commonly target University users with phishing emails. They usually include a link that redirects users to a fake web login page that appears at first glance to be one of the University web login pages.
Fake web login pages are under the control of criminals. Once users have been tricked into entering their University username and password in a fake web login form, cyber criminals can use their accounts to access their personal information and commit other frauds, such as sending phishing emails on behalf of the user’s account compromised.
When you came across a website that asks for your University Webauth or Nexus credentials, before entering your password, make sure you are accessing to the authentic University web page. The following tips can help you to verify the authenticity of the University Webauth and Nexus login pages:
Tip 1: Recognize the network domain of the University web login pages:
The University Webauth login page begins with https://webauth.ox.ac.uk/. An example of the Webauth login page is shown below:
The University Nexus login page begins with https://owa.nexus.ox.ac.uk/. The screenshot below shows what the Nexus login page should look like:
Note that when you look at the address bar in your browser, the domain is the part from the double slash “//” to the first slash “/” .
Tip 2: Identify that the University login pages have a padlock icon in the address bar of your web browser, as can be seen below (Google Chrome web browser was used in this example):
Tip 3: Verify the website SSL certificates as they contain unique features. The following three steps will explain how to verify SSL certificates:
Note: Google Chrome web browser has been used in this example (for different web browsers steps may vary):
Step 1: Click the green padlock icon and select “Details”.
Step 2: The Security Overview section will be displayed in your browser, then select “View certificate”.
Step 3: The “Security Overview” section displays the following unique items that are characteristic from the Webauth and Nexus web login pages:
For the Webauth web login page:
Certificate name: webauth.ox.ac.uk
Issued by: QuoVadis Global SSL ICA G2
Look for the green tick, “This certificate is valid”
For the Nexus web login page:
Certificate name: owa.nexus.ox.ac.uk
Issued by: TERENA SSL CA 2
Look for the green tick, “This certificate is valid”
Do not enter your University credentials until you have verified the authenticity of the login page. If you find a fake login page that asks for your University credentials or you are unsure if it is legitimate, forward it to firstname.lastname@example.org. The security team will block fake web login pages to protect University users.
Posted in Email|Comments Off on How to recognize the University of Oxford Web Login Pages
Thursday morning began with a keynote from Prof Kilnam Chon of KAIST, entitled The Other Billion, considering the demands and challenges posed by the internet users expected to come online over the next few years, mostly in Africa and Asia. The speaker noted that FIRST currently has membership from around seventy nations and called upon us to look to double this as soon as we can. FIRST is working on this through its Fellowship Programme and through the running of smaller-scale regional meetings specifically targeting developing nations.
N Seoul Tower
A presentation followed on security metrics, with the message that one should always be thinking of novel metrics, explore the data, then see whether they are useful. Many good examples were presented, generally based on data readily available from Shodan. My favourite was a table of “universities needing toner”, determined from querying unfirewalled printers on their networks. Perhaps thankfully for us, this only looked at US universities!
The day concluded with the annual ritual of the AGM, including the all-important elections to the Board of Directors, hotly contested this year with the final place on the being a tie and having to be determined by a coin toss. Another important vote was to amend the quorum for future AGMs – with the expansion of the organisation, it has been increasingly difficult to ensure that the required number of team representatives (or their proxies) have been in attendance.
Not part of the AGM
Friday’s keynote was from Christopher Clark of Palo Alto Networks, looking at lessons learned from building a global security response team. While their team is on a vastly different scale to ours, it was interesting to see the similarities. In particular, while staff will have their own specialisations, they are nevertheless expected to have skills across a range of different areas, and all will have a balance of response and research as part of their role. Also there was a culture of automation; as a rule of thumb, any task performed three or more times should be considered for automation. Past talks from companies such as Google have encouraged a similar philosophy.
Drum at Deoksugungm Palace
Next up was internet pioneer Paul Vixie on DIY threat intelligence, in particular leveraging DNS Response Policy Zones. This is something we are using ourselves but there is scope to take much further. Some suggestions were hypothetical but might be appropriate for some sites, for instance, blocking entire top-level domains by default when they are widely abused (typically because they are very cheap or even free to use). He considered reputation-based filtering of domain registrars, and even considered the possibility of a “default deny” approach to DNS – probably a little too drastic for our environment!
Finally was a talk on using Windows event logs to track the movement of so-called “advanced persistent threats” (APTs) – essentially, looking for unusual activity such unauthorised use of domain administrator accounts.
Formal proceedings drew to a close at lunchtime, with the draw for sponsors’ prizes, thanks and closing remarks. Some delegates stayed on for various associated meetings or training in the afternoon and over the weekend, while others relaxed, started out for home, or else took some time to explore the city before doing so. (As indeed I did myself, not least to take some of the photos for these blog posts.)
Once again, a superb conference, packed with interesting presentations, information on useful tools and approached, and just as importantly, the value gained through informal conversations with other delegates over the course of the week. Next year’s conference will be another long-haul trip but in a different direction, namely in Puerto Rico, and we hope that once again OxCERT can be represented.
US-CERT presented on best practices and big mistakes in responding to major incidents. Their idea of major incidents is typically on a much greater scale to ours, with some investigations taking months. Their tips included good practice for all stages of the response process, as well as things not to do, for instance because they may lose critical evidence or tip off attackers that they’ve been noticed.
The final talk considered an approach to attracting young talent into the field of cybersecurity, in particular through the hosting of cybersecurity exercises and “capture the flag” competitions, though I do wonder whether how such approaches work in attempting to level the highly male-dominated gender balance within the industry.
The day ended with the conference banquet, held at Seoul’s LetsRun Park racetrack. Inclement weather that day meant that the plans to hold it outdoors had to be abandoned, but the venue offered copious interior space. Excellent entertainment was offered throughout the evening, ranging from traditional Korean music and dance to modern K-pop hits, naturally including Gangnam Style, named for the nearby district of Seoul.
Last week saw the annual conference of FIRST, the Forum for Incident Response and Security Teams, this time held in Seoul, South Korea. As usual this is a big event, with 670 attendees this year from over seventy nations, covering a very diverse range of companies and organisations.
The programme was as usual a busy one, with keynote sessions starting each day followed by a choice of breakout sessions (and a number of other meetings) running in parallel, at times resulting in a difficult decision as to which to attend.
Part of South Korea’s extensive border defences
Following a welcome reception on the Sunday evening, presentations began the following morning with a keynote from Professor Jong In Lim of Korea University, former Special Adviser to the President for National Security, discussing some of the security challenges faced at a national level, not least those coming from North Korea.
The next talk was technical analysis of Java remote access trojans and how they operate. It was interesting, if concerning, to hear that they are not just limited to Windows but that some variants exist for for Mac OS X, Linux, and Android. I followed this on one discussing the threats to corporate Exchange systems. Later I attended one on threats to corporate Exchange systems, of significantly greater concern than the the standard user account compromises such as those we encounter on a near-daily basis.
Gwanghwamun Gate at Gyeongbokgung Palace
Further talks on Monday included the mechanisms behind online advertising, and just how easy (and cheap) to present malicious adverts to thousands of vulnerable systems; then a talk on security notifications, in particular informing website owners of vulnerabilities on their sites, contacting them based on publicly available data. The day ended with a look at Cisco’s Malspider, a custom crawler for detecting website compromises. This is an open source tool and something that I feel warrants further investigation as a possible tool for us to use internally.
Several talks at the conference mentioned use of machine learning, particularly in terms of looking for suspicious activities in large volumes of data. At present, usage is not that extensive in threat detection but speakers predicted it becoming commonplace over the next 2-3 years.
Malware was something Sejong the Great never had to worry about
Tuesday’s keynote was from Clay Lin of the World Bank entitled The Journey of Building a 24×7 Incident Response Operation, an interesting view of how to establish a security team on a far larger scale than we have ourselves. Next was the initial meeting of a new Malware Special Interest Group, discussing its aims and means of operation.
The afternoon’s talks included one on creating a database of malware threat intelligence through analysis of the masses of samples submitted to Virustotal, and making this available through a malware information sharing platform or MISP. Another talk was on cyber-insurance and the value to be gained in at least considering it as part of a risk management strategy. This was followed by a series of brief “lightning” talks covering a diverse range of topics, and a vendor reception, an opportunity to keep up to date with some of the security products available, although many of them clearly come with a fairly hefty price tag.
You receive an email requesting a payment. It could be for rent, it could be fees for a course or any other legitimate reason. Typically, the payment is a significant sum. The email contains the banking details you need to make the payment. Then shortly after the 1st email arrives you receive a 2nd email. It says the banking details have changed. There was a mistake, they’re sorry etc. but here are the correct details. You make your payment using the new banking details.
Time passes. Nothing happens…
You contact the organisation to say you have paid. You weren’t expecting a thank you note but you were expecting at least some acknowledgement. Instead, they say;
‘You’ve paid? Really? We are not seeing any record of a payment’.
You get a sinking feeling. Where has your money gone?
So what went wrong?
Here is what we think is happening in these cases. The email requesting the initial payment was legitimate. But it went into an email account that was compromised. A fraudster had access to the account and was keeping an eye on the emails coming into it. They might have been doing this for some time. We have seen this with accounts from service providers like Gmail or Yahoo (though there is no inherent reason why these email accounts shouldn’t be secure).
You might assume this is the banking system, and you do know exactly who you paid the money to, right? You have their account number, sort code etc. So the bank should be able to retrieve your money? Wrong. It’s unlikely that the bank account is controlled by the legitimate account holder. Any money you paid in will be moved out of the account almost immediately. This is money laundering. The money will be split and moved into other accounts with other banks all to hide its progress through the banking system before being integrated back and emerging for the fraudster to collect.
Bottom line is it’s unlikely that the process can be unwound to retrieve your money.
What is new is we are seeing fraudsters appearing to detect exploitable financial opportunities, like requests for payments and really pounce quickly. They can turn around a plausibly forged email attempting to redirect payments (with email signature / graphics etc.) in as little as 10-15 mins. This suggests some automation is involved; enough logic to spot simple patterns like banking details in otherwise routine email traffic and bring it to the fraudsters attention.
Preventing Payment Redirection Fraud
If you are sending out banking details, double check they are correct and tell recipients you won’t be changing them by email. Tell recipients they should immediately report any attempt to countermand the details as suspicious, but not by email because the fraudster may just intercept and delete the warning. If people follow this practice it defeats the fraudsters attempted redirection in its tracks. (The downside is if you really do need to change banking details you might have to write a letter to the recipients).
If you’re paying someone, using bank details they provided by email, and you receive a change to the banking details; don’t believe it! Find the contact details for the sender independently of the email, and check with the sender before you part with any funds. (A fraudster who forges an email can fake the contact details in the message – it could be the fraudster you end up calling and of course they will say the change is legitimate!).
If you have transferred money and it has not arrived, you need to act quickly. Stay calm:
talk to the fraud team at your bank and tell them what has happened
regain control of your email account by changing your password
tell OxCERT (or your local security team) so they can secure any logs as evidence
and, because this is a crime, ultimately, you are going to need to tell the police.
Everyone is busy at Christmas. As the old year ends people’s thoughts turn to making plans for traveling, for shopping, for celebrations and for what the new year might hold. We are distracted and perhaps a little more optimistic than usual. For fraudsters, ever the cynics, this might just offer the opportunity they need.
Many universities have reported seeing evidence of a phishing campaign targeting students during 2015. Emails arrive in student inboxes claiming to be from the ‘finance department’ or the ‘Student Loans Company’ and congratulating students on be being eligible for additional funds. The emails urged students to sign up to collect the funds and helpfully providing a link to do so. The emails can be well written, sound official and mention sources of authority; the university, the student loans company, and the government but they are a scam.
A recent example of the text of an email…
Date: 29 December 2015 at 09:42:58 GMT
Subject: Important university grant information
We are pleased to inform you that the university has been awarded funds for undergraduate study support by the government.
All undergraduate and postgraduate students studying on a full-time course are entitled to this grant. To ensure you receive your grant, you are required to submit your details via the web link below.
Please click on the link above or copy and paste it into your browser to submit your details.
Once processed, you will be contacted via your registered address with the university.
You should not follow the link in it. It may take you to a site attempting to trick you into disclosing sensitive financial information. The Oxford infosec site has more advice on how to avoid email scams.
It is perhaps alarmist to refer to this as a ‘backdoor’ right off the bat; a backdoor is a hole deliberately introduced into an otherwise strong and integral security system, to permit access to resources without going through proper authentication and authorisation. If your file server had a backdoor, placed there for example by a malicious user, that user might retain access to the server long after the administrator disables or deletes their ‘official’ account.
Copyright someone else entirely
Backdoors are also commonly installed by external hackers as a means of retaining access once their initial compromise vector is inevitably closed off, or by nosy nation states that prefer to know precisely which episodes of The Good Wife you’ve been watching, and when.
Fortinet themselves are referring to this as an “Undocumented Interactive Login Vulnerability”.
Make of that what you will…
To editorialise somewhat, this particular FortiOS ‘vulnerability’ appears more like a badly implemented management function than anything too sinister or underhanded. Vendors are well known for adding ‘back channel’ logins during firmware and product development, and to their shame a number of vendors have been caught out failing to properly disable their internal tools when the code is shipped to primetime.
In this case, Fortinet have already ‘fixed’ the problem; they contest that recent ‘supported’ releases of FortiOS do not suffer from this issue.
The patch notes for these versions do not mention the excision of any malicious backdoor code. It is difficult to speak to this inconsistency, it could be an elaborate coverup Fortinet have been praying would never come back to haunt them or it could merely represent the well-natured removal of a forgotten administrative protocol.
Shhhh I don’t think anyone noticed…
The Fortinet backdoor (I will refer to it as such from now on for the sake of convenience, as we shall see it is certainly not a front door…) operates in a slightly nonstandard fashion.
The management interface of the Fortinet appliance listens for SSH connections; it would be nice to live in a world where no such management interface is exposed to the world, but sadly we don’t live in that reality. Somewhere, a vulnerable FortiOS appliance is listening on an SSH port.
Sophisticated authentication protocol or what
The Proof of Concept script released to the world runs in the perennial favourite language for such things, Python. The original seclist disclosure of the backdoor code can be found here. By dissecting this script, we are able to determine how this particular backdoor operates.
The backdoor is triggered by an SSH connection to the Fortinet appliance, using a rather predictable username with a blank password. Now things get interesting.
Wait for it…
The Fortinet appliance responds to the interactive session with a numerical value; this is similar in operation to various One Time Password systems, and in fairness to Fortinet would have been pretty tough to reverse-engineer without the PoC code. The script accepts this numerical value, and from it calculates the password it must submit.
Wait for iiit…
The freshly minted password is submitted and….
I AM EENVEEENCIBUL!
In the words of my generation, pwned.
Did we mention that the FortiOS appliance hides all logs of these transactions from you, the diligent administrator?
Fortinet’s own remediation advice is really quite straightforward; patch to the latest version.
The most recent releases of the 4.3 and 5.0 FortiOS branches have the backdoor removed.
In the event that such an in-place upgrade is either impossible or too far out-of-band, there are some short-term workarounds that may help, specifically;
Disable SSH administrative access on all interfaces; you will rely on the Web GUI for all administrative tasks
Restrict direct SSH access to the smallest possible range of known-friendly IP addresses
These steps are good security practice in any case, the emergence of this backdoor simply underscores the need to ensure that administrative interfaces are locked down to the greatest possible degree.
On January 12th, OxCERT were speculating that tomorrow would bring a surge in inbound SSH traffic as various scanners began to pick up the exploit code, and this is precisely what happened;
Showing only Port 22, inbound to our Autonomous System
This output from our prototype NetFlow analytics system shows a fairly clear surge in Port 22 traffic just as news of the exploit was spreading across Reddit and various news sources like Arstechnica were gearing up for their evening reporting of ‘The Fortinet Backdoor‘.
Whilst it may come as somewhat of a surprise, Windows 8 will be unsupported as of next Wednesday (13th January).This comes about due to the fact that Microsoft classifies Windows 8.1 as a service pack and not a full new version of Windows, and as such requires it to be installed in order to continue receiving security updates. Furthermore, because Windows 8.1 is not delivered by Windows Update (it’s in the Windows Store) many people are completely unaware of its existence and will not realise they need to install it.
Once you’ve done so please take a moment to make sure that your staff, students, colleagues, friends and family have done so too; the top reason for devices to become infected with malware is via fully known but unpatched security vulnerabilities.
From here you can see that Windows 8 is under extended support (this means it gets security updates) until January 2023. However, if you look a little closer, you’ll see that it actually says that the latest “service pack or update” is Windows 8.1. This is explained a little further down:
Because Windows 8.1 has the same system requirements as Windows 8, it can be installed directly onto Windows 8 with no loss of data, and it is supplied completely free, Microsoft gave users 24 months to install it before dropping support for the old version. That time is nearly up.
Beginning Friday and continuing through the weekend, OxCERT’s network security monitoring has picked up an extreme number of PCs infected with the ‘Dridex’ family of banking malware.
This malware is a specialised form of computer virus, tailored specifically to Windows-based PCs and designed to quietly harvest user credentials and financial information.
Commonly-employed signature-based anti-virus packages are completely ineffectiveagainst this threat tier, Dridex is strongly resistant to antivirus detection once it has become resident on a machine and cannot be reliably removed even if discovered. OxCERT are able to detect some of the encrypted traffic signatures that the malware produces as a result of intensive in-house efforts to develop our monitoring capabilities, but sadly are unable to proactively prevent the infection of a machine.
We’re gonna need a bigger boat
This particular outbreak has been traced to malicious .XLS (Microsoft Excel) spreadsheet files, distributed to many University departments by email. The emails suggested that a bill was to be paid or an invoice satisfied, a common enough subject for the financial and Human Resources staff that the malware is designed to target.
Example Dridex Mail
Upon downloading and opening the attached .XLS file, staff discover that the document appears blank; in fact, the computer is already infected with the Dridex malware.
The current crop of infected .XLS files are ‘droppers’, macro-based mini-scripts hidden inside the .XLS files that then go on to download and install the malware proper.
As a result, if you are running Microsoft Office without macros enabled by default (either as Always Deny or Always Ask when macros attempt to run) you may be somewhat less vulnerable to this current threat.
Dridex is also capable, but not particularly fond of infecting network shares, user roaming profiles and detachable media such as USB keys etc. This is significant, as a user roaming profile could easier wander from one machine to another as the user logs on and off different machines. Cross-infection is by no means automatic or certain in these circumstances, it might for example rely upon the user finding and re-opening infected content from the profile while logged into a second machine, but this behaviour cannot be ruled out.
Dridex is an evasive, information-stealing malware variant; its goal is to acquire as many credentials as possible and return them via an encrypted tunnel to a Command-and-Control (C&C) server. These C&C servers are numerous and scattered all over the internet, if the malware cannot reach one server it will try another. For this reason, network-based measures such as blocking the C&C IPs is effective only in the short-term.
As far as we know, by default Dridex does not attempt to spread from one machine to another directly; this would draw attention to the infection. Instead the malware lies mostly dormant, monitoring keystrokes and email contents for long periods of time.
It should be noted that Dridex itself is not a macro virus, but the current infection vector we are seeing uses macros. This is important, as we are able to slow down the rate of infection by controlling the use of macros in Microsoft Office applications, but for machines already infected the damage has already been done. Sophos et al can sometimes detect ‘macro viruses’ on-disk, but if you have opened the attachment already then it is too late.
It is not possible to remove Dridex from an infected machine. If a staff member has opened an unfamiliar attachment or OxCERT have issued a warning about a machine, the following steps must be taken;
Quarantine the affected machine; remove its network connectivity and switch it off
Inform OxCERT immediately; email@example.com
Change ALL service passwords used on that machine, this includes personal accounts, social media, SSO logins and internal systems such as financial databases
Reformat the hard disk of the infected machine; do NOT use System Restore, this is ineffective and simply re-installs the malware
Re-install the Operating System from scratch using your locally preferred method
Do not use the re-installed machine until all security patches have been applied
ALSO: If a roaming profile has been used by any user on an infected machine, that profile must be completely wipedto ensure no lingering infection elements are present.
The mental checklist is as follows;
‘Phishing@it.ox.ac.uk’ would be the fourth ‘P’ but that ruins it
The only effective means of preventing the ‘dropper’ documents from downloading the main malware code is to change your macro settings in Microsoft Office;
Office 2013 dialogue example
For this Office 2013 example we would recommend ‘Disable All Macros with notification’
This will cause Office to ask you before running a macro; this will give you the time needed to check if a document is actually what you expect it to be, before launching the macros inside which could deliver the virus to your PC. This can make frequently-used macro documents quite inconvenient, but is a strong step forward in ensuring your safety.
To prevent future infections, the most effective tool is user awareness and vigilance. This threat relies on the user opening the document, it cannot infect a user without that crucial step.
All staff should be aware of the current threat status, and to exercise caution in opening attachments from any unfamiliar sources or companies.
Where there is doubt surrounding the authenticity of an email, staff should seek an immediate second opinion from a colleague or supervisor.
We appreciate this is less than ideal for departments receiving many hundreds of attachments per day, but it is our only effective defence against this threat at present. Only by looking out for and helping one another to recognise malicious emails can we prevent more departments and more users falling victim to this new threat.
As ever, OxCERT and the Infosec Team (firstname.lastname@example.org) are available to offer advice, although our response times at present may be slower than usual.
For the more technically-curious, there is a short excerpt from the recent CeBit 2015 conference, in which world-renowned hacker-turned-security-pro Kevin Mitnick demonstrates precisely how this kind of malware is delivered to a user, how a user is enticed to open it, and the subsequent malware installation that quietly seizes control of the victim’s machine.
The PC in the following clip is fully up-to-date with security patches, and is running a common signature-based antivirus product.
This may serve to illustrate just how short the distance is between ‘Clean’ and ‘Infected’; in the clip, Mitnick is able to ‘Uninstall’ his malware because he himself created it and uses a built-in function to do so, but to attempt to remove his code by force (either by running antivirus or deleting files from disk, modifying registry settings etc) would be doomed to failure. The only safe course is scorched earth, reinstall the system from bare metal upwards.
OxCERT have received an escalating number of reports of highly convincing financial fraud emails directed at University Finance Officers and others responsible for issuing large financial payments.
It’s that time again folks
This threat goes beyond simple ‘phishing’ campaigns, this is clearly a direct and deliberate targeted criminal campaign against the University, with the goal of extracting large sums of money (on the order of thousands of pounds) from individual department ledgers. All Financial Officers and people with similar responsibilities should read this alert with care and apply this advice to their daily practice without fail, the risk of financial losses to this campaign is unusually great.
The fraud attempts have so far been exclusively received by email, and take the form of a very convincing and well-phrased email requesting the initiation of a transfer:
This looks like it came from the Head of Department or another highly-placed individual, and is intended to entice the Financial staff member to respond. Let us assume that the member of staff is fooled by the original email, and responds as they would to the real Head of Department;
The email will not go to the Head of Department, as these emails have a manipulated Reply-To header; instead, the email will go to an email account under the control of the criminals. These criminals are actively monitoring these email addresses for ‘hits’, Financial Officers of the University responding to their initial probe. If a response is received, further details will be requested:
As you can see, this is all quite legitimate-seeming and it is easy to forget to authenticate the request properly. We are not aware of any departments actually transferring funds to the fraudsters, but we are aware that members of staff have been initially taken-in and have replied to the initial probe emails.
The characteristic of these emails is a forged Reply-To field; the criminals cannot actually allow you to reply to the Head of Department they are impersonating, as that would give the game away immediately. Instead they add an extra email header to tell your client program to respond to a different address than the (forged) sender address. This is normally hidden by many email clients, so you need to re-enable the ability to see more email headers:
Always do this….
…and always check this.
In this example Thunderbird is used and your mail client may differ, but the Return-path information will always let you confirm that the email is really going to the email address you think it’s going to. This does not protect you against another member of staff having their account compromised however, so you should still verify any out-of-the-ordinary transactions directly with the individual.
Check all email headers for all emails requesting financial transfers
Ensure the Reply-To or Return-path fields match the sender you expect
Check with the individual that they did in fact request this transfer