Office for Mac supports the three most recent versions of Apple's macOS. With the release of macOS 10.15 Catalina, Microsoft 365 for Mac and Office 2019 for Mac support macOS 10.15, 10.14, and 10.13
 
Microsoft 365, Office 2019 for Mac:
As of the November 2020 (build 16.43) update for Microsoft 365 for Mac or Office 2019 for Mac, macOS 10.14 Mojave or later is required to receive updates to Word, Excel, PowerPoint, Outlook and OneNote. If you continue with an older version of macOS, your Office apps will still work, but you'll no longer receive any updates including security updates.
 
Upgrading your operating system to macOS 10.14 or later will allow Office updates to be delivered for your apps. Note that new installs of Microsoft 365 for Mac or Office 2019 for Mac will also require macOS 10.14 or later.
 
Microsoft 365, Office 2016 for Mac:
Support for Office 2016 for Mac will end on October 13, 2020. All your Office 2016 apps will continue to function—they won't disappear from your Mac, nor will you lose any data. Learn what Office 2016 for Mac end of support means for you
 
Word, Excel, PowerPoint, Outlook, and OneNote will install and run on OS X 10.10 Yosemite and later.
 
For the best experience with 10.15 Catalina, be sure to keep your Office apps up-to-date. If the version of Office installed on your Mac is earlier than 16.16, and you are not being offered updates, you can download the latest Office for Mac suite installer. See What version of Office am I using?.

Incorrectly handling a ransomware incident can hinder recovery efforts, jeopardize data and result in victims paying ransoms unnecessarily. In the wake of a ransomware attack, organizations should avoid the following mistakes:

1. Do NOT restart impacted devices.
Organizations should avoid restarting devices that have been impacted by ransomware. Many ransomware strains will detect attempts to reboot and penalize victims by corrupting the device’s Windows installation so that the system will never boot up again, while others may begin to delete encrypted files at random. The infamous Jigsaw ransomware, which was prolific in 2016, randomly deleted 1,000 encrypted files each time an infected device was rebooted.
Restarting the system can also hinder forensics efforts. Rebooting clears the machine’s memory which, as noted earlier, may contain clues that can be useful for investigators. Instead, impacted systems should be put into hibernation, which writes all data in memory to a reference file on the device’s hard disk, which can then be used for future analysis.

2. Do NOT connect external storage devices to infected systems.
Many ransomware families intentionally target storage devices and backup systems. As such, external storage devices and backup systems must not be connected (physically or via network access) to infected systems until organizations are fully confident that the infection has been removed.
It is not always obvious that ransomware is running. Sadly, there have been many cases of businesses commencing the recovery process without realizing that ransomware is still present on their system, resulting in ransomware encrypting their backup systems and storage devices.

3. Do NOT pay the ransom immediately.
While the prospect of downtime and potential reputational loss can be daunting, organizations should not immediately pay the ransom. There are always other options, and these should be explored in full before resorting to paying the ransom.

4. Do NOT communicate on the impacted network.
During recovery, victims should assume that attackers still have access to the compromised network and therefore may be able to intercept any communications that are sent and received over the network. Organizations should establish secure out-of-band communication channels and prohibit users from communicating on the compromised network until remediation is complete and the network is clear of intruders.

5. Do NOT delete files.
Files should not be deleted from encrypted systems unless a ransomware recovery specialist has advised to do so. Not only are encrypted files useful for forensics, but some ransomware families store encryption keys within the encrypted files – if the files are deleted, the decryptor won’t work.
Similarly, ransom notes should never be deleted. Some ransomware families, such as DoppelPaymer and BitPaymer, create a ransom note for every file they encrypt, which contains the encoded and encrypted key necessary for decryption. If a ransom note is deleted, its corresponding file cannot be decrypted.

6. Do NOT trust ransomware authors.
Despite increasingly trying to adopt a facade of professionalism, ransomware authors are criminals who are not obligated to uphold any agreements or abide by any code of ethics. Organizations should not believe any information provided by ransomware groups, including information in the ransom note (such as the ransomware strain) nor trust that paying the ransom will lead to the recovery of encrypted data.

Victims should be mindful that attackers may not provide a decryptor after payment, and that attacker-provided decryption tools may be faulty and/or potentially damage encrypted data.

So you don't have a plan or system in place for Disaster Recovery and Business Continuity, that's a shame because you could avoid reading this guide all together if you did.

In the event of a ransomware attack, an effective response plan can mean the difference between panic and decisive action. It can mean the difference between a company-wide infection and a contained incident; the difference between swift remediation and permanent business closure.

In this guide, we’re going to discuss in detail exactly how businesses should respond to a ransomware attack and explore preventative measures that can help reduce the risk of infection.
How to respond to a ransomware attack. If preventative measures fail, organizations should take the following steps immediately after identifying a ransomware infection.

1. Isolate affected systems.
Isolation should be considered top priority. The vast majority of ransomware will scan the target network, encrypt files stored on network shares and try to propagate laterally to other systems. To contain the infection and prevent the ransomware from spreading, infected systems must be removed from the network as soon as possible.

2. Secure backups
While backups play a crucial role in remediation, it’s important to remember that they are not immune to ransomware. To thwart recovery efforts, many modern ransomware strains will specifically target a company’s backups and try to encrypt, override or delete them.
In the event of a ransomware incident, organizations must secure their backups by disconnecting backup storage from the network or locking down access to backup systems until the infection is resolved.

3. Disable maintenance tasks
Organizations should immediately disable automated maintenance tasks such as temporary file removal and log rotation on affected systems, as these tasks can interfere with files that may be useful for investigators and forensics teams.
For example, file logs may contain valuable clues regarding the initial point of infection, while some poorly programmed ransomware variants may store important information (such as encryption keys) inside temporary files.

4. Create backups of the infected systems
Organizations should create backups or images of the infected systems after isolating them from the network. There are two main reasons for doing so:
Prevent data loss. Some ransomware decryptors contain bugs that can damage data. For instance, the decryptor of a prolific ransomware family known as Ryuk was known to truncate files, effectively cutting off one byte of each file during the decryption process. While this didn’t cause major issues for some file formats, other file types – like virtual hard disk files formats such as VHD/VHDX as well as a lot of Oracle and MySQL database files – store important information in the last byte and were at risk of being corrupted after decryption.
Having a backup of infected systems ensures data integrity. If something goes wrong during the decryption process, victims can roll back their systems and try to repeat the decryption, or contact a ransomware recovery specialist for a reliable, custom-built decryption solution.
Free decryption may be possible in the future If the encrypted data is not critical to an organization’s operations and does not need to be urgently recovered, it should be backed up and stored securely as there’s a chance that it may be able to be decrypted in the future.
There have been instances of law enforcement agencies apprehending ransomware authors and C&C servers being found, which resulted in the release of decryption keys and allowed victims to recover their data for free. In addition, a number of ransomware groups – including Shade, TeslaCrypt and CrySis, among others – have willingly released decryption keys after shutting down their operations.

5. Quarantine the malware
Victims should never outright remove, delete, reformat or reimage infected systems unless specifically instructed to by a ransomware recovery specialist. Instead, the malware should be quarantined, which allows investigators to analyze the infection and identify the exact strain of ransomware responsible for encrypting files. Removing the entire infection makes it extremely difficult for recovery teams to find the specific ransomware sample involved in the attack.
If the malware is still running, memory dumps should be made prior to quarantine to create a full record of any malicious processes that are running. The memory dump may contain the key material that was used to encrypt the files, which can potentially be extracted and used to help victims decrypt files without paying the ransom.

6. Identify and investigate patient zero
Identifying patient zero (i.e. the source of the infection) is crucial for understanding how attackers gained access to the system, what other actions they took while they were on the network and the extent of the infection. Detecting the source of the infection is useful for not only resolving the current incident, but can also help organizations address vulnerabilities and reduce the risk of future compromise.
It can be challenging to identify the original point of compromise because, in many cases, the threat actors will have been on the system for weeks or even months before deploying the ransomware payload. Companies that lack the resources or expertise to perform thorough digital forensics should consider enlisting the services of a professional forensics company.

7. Identify the ransomware strain
Organizations can use free services such as Emsisoft’s online ransomware identification tool or ID Ransomware to determine which strain of ransomware they have been impacted by.
These tools allow users to upload a ransom note, a sample encrypted file and the attacker’s contact information, and analyze the data to identify which ransomware strain has impacted the user’s files. It also directs the user to a free decryption tool if one is available.

8. Decide whether to pay the ransom
If backups are damaged and there is no free decryption tool available, organizations may be tempted to pay the ransom in order to recover their files.
While paying the ransom can help reduce disruption and may be cheaper than the overall cost of downtime, it is not a decision that should be taken lightly. Organizations should only consider paying the ransom if all other options have been exhausted and the loss of data will likely result in the company going out of business.
The following factors should be considered:

• There is a 1 in 20 chance that the ransomware authors will take the money but not provide a decryptor. Generally speaking, larger, more “professional” ransomware gangs are more likely to provide a working decryptor than variants that are typically sold to and run by individuals, such as Dharma and Phobos. Regardless of who is behind the attack, victims have to rely on criminals to provide a decryptor with no guarantee that they’ll hold up their end of the bargain.
• The attacker-provided decryptor may not work properly.
• Ransom payments may be used to fund serious criminal activity, including human trafficking and terrorism.
• Paying the ransom substantiates the ransomware business model and perpetuates further attacks.

​
With the help of ​Emsisoft.

Apart from some slightly clumsy wording (but when was the last time you received an email about a technical matter that was plainly written in perfect English?) and a tiny error of grammar, we thought it was surprisingly believable and worth writing up on that account, to remind you how modern phishers are presenting themselves.

Yes, you ought to be suspicious of emails like this. No, you shouldn’t click through even out of interest. No, should never enter your email password in circumstances like this.
But the low-key style of this particular scam caught our eye, making it the sort of message that even a well-informed user might fall for, especially at the end of a busy day, or at the very start of the day after.
​
Here’s how it arrives – note that in the sample we examined here, the crooks had rigged up the email content so that it seemed to be an automated message from the recipient’s own account, which fits with the theme of an automatic delivery error:

​Only if you were to dig into the email headers would it be obvious that this message actually arrived from outside and was not generated automatically by your own email system at all.
The clickable link is perfectly believable, because the part we’ve redacted above (between the text https://portal and the trailing /owa, short for Outlook Web App) will be your company’s own domain name.

But even though the blue text of the link itself looks like a URL, it isn’t actually the URL that you will visit if you click it.
Remember that a link in a web page consists of two parts: first, the text that is highlighted, usually in blue, which is clickable; second, the destination, or HREF (short for hypertext reference), where you actually go if you click the blue text.
​
A link is denoted in HTML by an ANCHOR tag that appears between the markers <A> and </A> while the destination web address is denoted by an HREF attribute inside the opening anchor tag delimiter.
Like this:

Why not just block links that look deceptive?
If you’re thinking that “links that deliberately look as though they go somewhere else” sound suspicious, you’d be right.

You might wonder why browsers, operating systems and cybersecurity products don’t automatically detect and block this kind of trick, where there’s an obvious and deliberate mismatch between the clickable text and the link it takes you to.

Unfortunately, even mainstream sites use this approach, making it effectively impossible to rely up front on what a link looks like, or even where it claims to go in your browser, in order to work out exactly where your network traffic will go next.
​
For instance, here’s a Google search for here's an example:

You can see that if you ① search for here's an example, you’ll receive a answer in which ② an explicit domain name (in this case, english.stackexchange.com) is used as the visible text of a clickable link.
You can also see that when you hover over the domain name link, you’ll see ③ a full URL that apparently confirms that clicking the link will take you to the named site.
​​However, if you use Firefox’s Copy Link Location option to recover the ultimate link, you’ll see – thanks to the magic of JavaScript – that your web request actually goes to a URL of this sort:

Eventually, you will end up at the URL shown at position ③ in the screenshot above, but you’ll be redirected (quickly enough that you might not notice) via a Google track-and-redirect link first.
So you do end up where the browser told you, but not quite as explicitly and directly as you might have expected – you get there indirectly via Google’s own advertising network.

What happens next?
The good news is that in the case of this phish you will see the actual web page you’ll be taken to if you hover your cursor over the link-that-looks-like-a-different-link.
That’s because email clients and webmail systems generally don’t allow JavaScript to run, given that emails could have come from anywhere – even if they say they came from your own account, as this one does.

So you ought to spot this phish easily if you stop to check where the link-that-looks-internal really ends up.
In our case (note that the exact URL and server name may vary every time), the real link did not go to https://portal.[REDACTED]/owa, as suggested by the text of the link.
Instead, it went to a temporary Microsoft Azure cloud web storage URL, as shown below, which clearly isn’t the innocent-looking URL implied in the email:

The phishing page
If you do click through, and your endpoint or firewall filter doesn’t block the request, you will see a phishing page that we must grudgingly admit is elegantly simple:
​​

Your email address is embedded in the link in the email that you click on, so the phishing page can fill in the email field as you would probably expect.
When we tried this page, deliberately putting in fake data, we received an error message after the first attempt, as though we’d made a mistake typing in the password:

No matter what we did the second time, we achieved “success”, and moved onwards in the scam.

How it ends
One tricky problem for phishing crooks is what to do at the end, so you don't belatedly realise it's a scam and rush off to change your password (or cancel your credit card, or whatever it might be).
In theory, they could try using the credentials you just typed in to login for you and then dump you into your real account, but there's a lot that could go wrong.
The crooks almost certainly will test out your newly-phished password pretty soon, but probably not right away while you are paying attention and might spot any anomalies that their attempted login might cause.
​
They could just put up a "thanks, you may now continue normally" page, and often that's exactly what they do as a simple way to sign off their scam.
Or they find a page that's related to the account they were phishing for, and redirect you there.
This leaves you on a web page that really does have a genuine URL in the address bar – what's often called a decoy page because it leads you out at the end of the scam with your innocence intact.
That’s what happened here – it’s not perhaps exactly the page you might expect, but it’s believable enough because it leaves you on a genuine Outlook-related web page with a genuine Microsoft URL:

Thanks:
Paul Ducklin, Sophos.