Security
Phishing Response Guide
If you're an MSP and manage an organization's infrastructure, sooner or later, you'll be faced with a phishing attack against the organization. What can you do to respond to such an attack in order to control possible damage and prevent further disruption? Keep reading for tips.
This guide addresses immediate phishing response actions that you can take following a phishing attack. As someone who has crossed this bridge many times, I have decided to put together a checklist of remediation actions against a phishing attack, along with Powershell scripts that are intended to help with automating some of the actions you can take in response.
For more information about phishing please refer to our guide on the topic:
Further reading Anti-Phishing Guide
Phishing Response Checklist Overview
The response checklist that follows assumes you are utilizing an Office 365 environment but can also be generalized for other email providers like Google Suite but the ensuing steps may differ.
- Block the phishing URL on Firewalls, AV endpoints
- Block the sender’s email
- Conduct an email compliance search to return lists of users who opened/received the email
- Purge the malicious email from all email inboxes
- Reset affected users’ passwords and log them out of active sessions (based on the report from step 3):
- If a small subset of users is affected:
- Reach out to affected users by phone to reset password
- If users reach out first, confirm identity by calling the user back using the phone number on record
- Reach out to affected users by phone to reset password
- If the affected pool is larger:
- Reset affected users’ passwords using the “change on login” option and export the list of generated passwords. Notify a supervisor by phone with a list of affected users and generated passwords, and by message prompt on computers
- If a small subset of users is affected:
- Run a search for inbox rules and forwarding rules and delete suspicious rules:
- Rules that forward the email to external domains
- Rules that move, delete or block messages
- Check the creation date and rule description that matches suspicious actions (these will usually have similar names as the inbox rules); it should be easy to determine that it was created by a bot and not by a human
- Run a search for mail sent out from possibly hacked accounts:
- Instruct affected users to reach out to clients by email and phone alerting them of malicious emails that may have been sent out from their accounts
- Turn on MFA for compromised accounts and provide a guide to users to get them properly set up
From the author: "Based on my experience managing over 4000 mailboxes across 300+ clients, a lot of users are not a fan of MFA. I am personally not a fan of Microsoft's implementation on MFA. I have found it to be annoying, disruptive, and clunky. At times it prompted users to use MFA when the device was already trusted and authenticated with MFA. Hopefully, they resolved these issues, which is possible; we haven't tested it for around six months. Otherwise, Duo is a great third party MFA provider and integrates well with Office 365, but of course, it comes with a cost that our clients would like to avoid."
Further reading Rising Tide of Malicious Links: VIPRE Report Highlights 85% Phishing Email Involvement in Q2 2023
Check out these marketing templates that we created to help MSPs sell Microsoft 365 as a managed service:
Download a set of free white-label templates designed to help MSPs sell Microsoft 365 as a managed service.
Phishing Response Checklist in Detail
Further, in this guide, we consider the process of responding to a phishing attack on the example of Office 365. If you run a different email app, details may vary.
#1 Blocking URLs
The idea here is pretty simple - block the phishing URL on firewalls and endpoints. Even if only one of your clients was hit, I would suggest blocking the URL on all your clients’ managed firewalls and endpoints.
Hopefully, you have some sort of management tool that allows you to make changes on all managed firewalls in bulk. As an example, Sonicwall offers this with GMS, Sophos provides it with the Sophos Firewall Manager portal, and other vendors should offer something similar to carry this out. Don’t forget to block the URL in your managed antivirus endpoints.
#2 Blocking the Sender Address or Sender Domain
As an extra measure of safety, I would recommend blocking the sender’s domain. As long as you can verify that the domain is malicious or fake, or your clients would never communicate with this sender domain, then just go ahead and block it.
Otherwise, if the sender domain happens to be authentic and there is a possibility that your client would conduct legitimate communication with it, you can just block the sender’s address instead.
It’s definitely possible that a legitimate sender address or even an entire sender domain was compromised. In such an unfortunate event, you’re better off going nuclear and blocking the entire sender domain for now. In the meantime, you can always reach out to their IT administrators to alert them that their account(s) have been compromised.
Luckily, in any event, Office 365 offers an easy way to block the sender address or domain within the Exchange Admin Center GUI or by using a Powershell script.
In a situation where you are managing more than a few Office 365 tenants, it helps to have a script that offers a simple way to loop through all your Office 365 managed tenants and run a series of commands. I have written such a script that does exactly that.
The script below should serve as your MAIN script or function to run to connect to your desired Office 365 managed tenants. It offers the option of connecting with an Exchange remote session using either a direct connection with direct (non-delegated) credentials, connecting to a specified Office 365 partner-managed tenant (delegated), or connecting to all Office 365 partner-managed tenants.
It works by connecting, then looping through each tenant. It can run any series of Exchange and Office 365 commands against them. You can use it to generate a license report, pull a list of users, and so on; the possibilities are virtually endless. But for the sake of this article and this step, we are going to use it to loop through all our Office 365 managed tenants and block the malicious sender domain or address.
[CmdletBinding()]
Param(
[Parameter(Position=0,mandatory=$true)]
[ValidateSet('DirectTenant','SpecifiedTenant', 'AllTenants')]
[string]$ConnectMode,
[Parameter(Position=1,mandatory=$false)]
[String]$TenantDomain
)
# ================================
# START FUNCTIONS
# ================================
Function Get-o365MsolTenants{
[CmdletBinding()]
Param(
[Parameter(Position=0,mandatory=$true)]
$SecureCreds,
[Parameter(Position=1,mandatory=$false)]
$SingleTenantDomain = $null
)
Try{
Import-Module MsOnline -ErrorAction Stop
}Catch{
Write-Warning 'You have to install MSonline module first by running "Install-Module MSOnline"'
Pause
Exit 1
}
Write-Host "Connecting To o365 MSol Service" -ForegroundColor Green
Connect-MsolService -Credential $SecureCreds
if($SingleTenantDomain -ne $null){
$SingleID = (Get-MsolPartnerContract -DomainName $SingleTenantDomain).TenantId.GUID
Return $SingleID
}
Else{
$IDs = (Get-MsolPartnerContract).TenantId.GUID
Return $IDs
}
}
Function Import-o365ExchSession{
[CmdletBinding()]
Param(
[Parameter(Position=0,mandatory=$true)]
$SecureCreds,
[Parameter(Position=1,mandatory=$true)]
$TenantDomain,
[Parameter(Position=2,mandatory=$true)]
[ValidateSet('DirectTenant','SpecifiedTenant', 'AllTenants')]
[string]$Mode,
[Parameter(Position=3,mandatory=$false)]
[String[]]$ImportCommands = $null
)
$null = Get-PSSession | Remove-PSSession
$ExchSession = $null
if($mode -eq 'DirectTenant'){
$URI = 'https://outlook.office365.com/powershell-liveid/'
}
Else{
$URI = ('https://ps.outlook.com/PowerShell-LiveID?DelegatedOrg=' + $TenantDomain)
}
Write-Host "Mode type is $Mode" -ForegroundColor Magenta
Write-Host "URI is: $URI" -ForegroundColor Magenta
$ExchSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $URI -Credential $SecureCreds -Authentication Basic –AllowRedirection
if($ImportCommands -eq $null){
$ImportExchSession = Import-PSSession $ExchSession -WarningAction SilentlyContinue -InformationAction SilentlyContinue -FormatTypeName * -DisableNameChecking -AllowClobber
}
Else{
$ImportExchSession = Import-PSSession $ExchSession -WarningAction SilentlyContinue -InformationAction SilentlyContinue -CommandName $ImportCommands -FormatTypeName * -DisableNameChecking -AllowClobber
}
return $ImportExchSession
}
# ================================
# SET YOUR CUSTOM SCRIPT BLOCKS
# ================================
# ================================
# Specify Your Custom EXCHANGE Commands
# In The sbCustomCommands Script Block
# ================================
$sbCustomExchCommands =
{
# Input custom Exchange commands below here
# Example:
# Set-HostedContentFilterPolicy `
# -Identity 'Default' `
# -BlockedSenders 'ExampleEmailAddress@Domain.com' `
# -BlockedSenderDomains 'ExampleDomain.com'
}
# ================================
# Specify Your Custom MsOnline Commands
# In The sbCustomCommands Script Block
# ================================
$sbCustomMsolCommands =
{
Param(
[Parameter(Position=0,mandatory=$false)]
[String]$MsolTenantID
)
# Input custom MsOnline commands below here
# Specify parameter -TenantID by each command to..
# run against a partner-managed tenant
# Example for running against partner tenant:
# Set-MsolUser 'user1@example.com' -TenantId $MsolTenantID
# Example for running against direct tenant:
# Simply exclude the '-TenantId' parameter
# Set-MsolUser 'user1@example.com'
}
# ================================
# SET VARIABLES
# ================================
# Specify list of Exchange commands to import into session.
# This is preffered instead of letting the Exchange session import
# all commands available as that of course will take a lot longer.
# Example:
# $ExchCommands = ('Get-Mailbox','Set-Mailbox')
$ExchCommands
# ================================
# Start MAIN
# ================================
If($ConnectMode -ne 'AllTenants' -and $TenantDomain -eq $null){
Write-Host "TenantDomain parameter is required if you have set ConnectMode parameter as DirectTenant or SpecifiedTenant" -ForegroundColor Red
Write-Host "Exiting" -ForegroundColor Red
Pause
Exit 1
}
$o365Creds = Get-Credential -Message 'Input o365 Credentials'
if($ConnectMode -eq 'AllTenants'){
# Clear Variables
$o365Tenant = $null
$TenantIds = $null
# Get list of tenants by running our Get-o365MsolTenants Function
Write-Host "Getting list of all tenants"
$TenantIds = Get-o365MsolTenants -SecureCreds $o365Creds
# Loop through tenants
$i = 0
foreach($CurTenantId in $TenantIds){
$i++
# Get the domain name of tenant to import Exchange session with
$CurTenantDomain = (Get-MsolDomain -TenantId $CurTenantId | ? {$_.IsDefault -EQ $true}).Name
Write-Host "Current Domain is: $CurTenantDomain" -ForegroundColor Magenta
Write-Progress -Activity "Going Through o365 Tenants....." -Status "Current Tenant: $CurTenantDomain $i of $($TenantIds.count)" -PercentComplete (($i / $TenantIds.Count) * 100) -Id 1
# Start o365 Exch Session for this domain
Import-o365ExchSession -SecureCreds $o365Creds -TenantDomain $CurTenantDomain -Mode $ConnectMode -ImportCommands $ExchCommands
# Invoking your custom Exchange commands script block
Write-Host "Starting your custom Exchange commands from sbExchCustomCommands script block" -ForegroundColor Yellow
Invoke-Command -ScriptBlock $sbCustomExchCommands
# Invoking your custom MsOnline commands script block
Write-Host "Starting your custom Msonline commands from sbMsolCustomCommands script block" -ForegroundColor Yellow
Invoke-Command -ScriptBlock $sbCustomMsolCommands -ArgumentList ($CurTenantId)
}
}
Else{
If($ConnectMode -eq 'SpecifiedTenant'){
Write-Host "Getting Tenant ID for $TenantDomain" -ForegroundColor Yellow
$SingleTenantId = Get-o365MsolTenants -SecureCreds $o365Creds -SingleTenantDomain $TenantDomain
Write-Host "TenantID for $TenantDomain is: $SingleTenantId" -ForegroundColor Magenta
}
# Start o365 Exch Session for this domain
Import-o365ExchSession -SecureCreds $o365Creds -TenantDomain $TenantDomain -Mode $ConnectMode -ImportCommands $ExchCommands
# Invoking your custom Exchange commands script block
Write-Host "Starting your custom Exchange commands from sbExchCustomCommands script block" -ForegroundColor Yellow
Invoke-Command -ScriptBlock $sbCustomExchCommands
# Invoking your custom MsOnline commands script block
Write-Host "Starting your custom Msonline commands from sbMsolCustomCommands script block" -ForegroundColor Yellow
Invoke-Command -ScriptBlock $sbCustomMsolCommands -ArgumentList ($SingleTenantId)
#3 Who Reads The Malicious Email?
The next step is to get a list of users who read the malicious email and to purge the malicious email from every inbox. Once we determine the list of users, we will need to take additional steps to secure those accounts.
To get the list of users who read the email, you will need to access the Office 365 Security and Compliance Center. From there you can run a Compliance Search to search for the malicious email across all inboxes and generate a report of the results.
The search is capable of searching all mailboxes, but it does have some limitations. It can only return up to ten results per mailbox. If you’re just searching for one unique malicious email across all mailboxes, which is likely the case, that limitation shouldn’t be an issue.
Another limitation that I encountered is that you cannot retrieve an export of the results in CSV format using Powershell. Instead, you have to go into the Compliance Center within the Office 365 portal and retrieve the results from there manually. There are some other limitations as well, but for the purposes of this article, which is Phishing Remediation, the above two limitations are the only ones that are relevant.
To start the search, you need to make sure your Office 365 user account has the necessary roles to conduct the compliance search, and the ability to export the results.
The steps to conducting the compliance search are as follows:
- Log into the search and compliance center at https://protection.office.com/ with Microsoft Edge or the latest version of Internet Explorer
- Unfortunately, you won’t be able to download the reports using any other browser
- On the left navigation pane, expand “Search and Investigation” > “Content Search”
- Create a new search
- Be specific with the conditions to ensure the results are accurate. Specify the following conditions:
- The sender > Sender’s email address of the malicious email
- Subject > Subject of the malicious email
- Received (Date) > If the email was received today, select dates ranging between today through tomorrow.
- Modify the “Specific Locations” and select all by Exchange
- Save As > Name it something simple and descriptive (e.g. “PhishingEmailHR”)
- After you save it, it will start running the search, which shouldn’t take long if you set the conditions to specific criteria as directed above
- Go back to the saved searches area > Refresh
- You should now see your saved content search
- Open your search > A right window pane will open
- Click More > Export Report
- You will want a report instead of the results option as the report will provide you with a CSV export instead of PST export(s)
- Now go to the Exports area
- Locate the title of your content search, it should have the suffix “_ReportsOnly” appended to it > Click your report > a right window pane will open
- Click Download Report > use the generated key it provides, and select a location for download
- Once the download completes, open the “Results.csv” file
- Briefly go through it and verify that the results are accurate. Each row should show details about the malicious email like Sender, recipient, location path in the inbox, etc. You just need to ensure the report only contains results pertaining to the malicious email, since later we will purge any email matching this report and we want to be careful to avoid purging anything other than the malicious email
- You will notice a column called “Is Read”; filter the column where it equals TRUE
- You should now see which users read the malicious email
- Compile a list of those users into a CSV file with just the headers “Email” and “Is Read”
#4 Purge The Malicious Email
At this point, we can proceed with purging the malicious email. To do so, you will need to connect to the Office 365 Security and Compliance center with Powershell. It does not currently provide a way to connect using delegated partner credentials, so you will need to use global admin account credentials for this Office 365 tenant.
The script below will purge the malicious email based on the results it found from the compliance search you ran.
01 Param( 02[Parameter(Position=0,mandatory=$true)] 03[string]$SearchName 04 ) 05 $SecureCreds = Get-Credential -Message 'Input o365 Global Admin Creds' 06 07 $URI = 'https://ps.compliance.protection.outlook.com/powershell-liveid/' 08 09 $ComplianceSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $URI -Credential $SecureCreds -Authentication Basic –AllowRedirection 10 Import-PSSession $ComplianceSession 11 12 13 # Run Get-ComplianceSearch Before To Return List of Searches 14 15 # Be careful, this will delete any of the results found across all mailboxes 16 # that this search was run against. 17 # It is not a hard purge, instead it just deletes the email from the inbox 18 # But can be recovered from the recoverable items folder 19 New-ComplianceSearchAction -SearchName $SearchName -Purge -PurgeType SoftDelete
#5 Reset User Passwords For Anyone That Opened The Email
Now that we have the report from step 3, we can determine who read the email by filtering out the list with the “READ” column where values equal “TRUE”. I would recommend calling the users if it’s a small handful of them. Otherwise, reach out to their branch office and have their supervisor notify them about the account password reset.
If the users are synced with an on-premise active directory server using Azure AD Connect/Sync, you will need to reset their passwords from the AD server and then run an AD sync cycle of the delta.
If they are all cloud accounts, you can quickly reset their passwords with a randomly generated password for each.
The script function below will reset the user's password. Note that this script is for a direct account only and not a partner account. If you need to run this on a partner account, set the tenantid parameter by each Msol Command.
The function will take in an array of UPNs and reset the password with an auto-generated password for all, set the forcechangepassword flag on login to true and export the results to a CSV.
Once the affected accounts' passwords are reset, reach out to the supervisor of the office and have him print out the generated passwords list and direct the affected staff members to log in with these temporary passwords in this list. These passwords should not be emailed in plain email communication. Try sending it out with message encryption or as an encrypted file and provide the password to unlock the file over the phone.
01 Function Reset-o365Passwords{
02
03
04 Param(
05[Parameter(Position=0,mandatory=$true)]
06[string[]]$UPNs,
07[Parameter(Position=1,mandatory=$true)]
08[string]$CsvOutputPath
09 )
10 $UserTable = @()
11 $Results = @()
12ForEach($Upn In $UPNs){
13 $User = $null
14 $Status = $null
15 $GetUserErr = $null
16 $SetPwErr = $null
17 $NewPw = $null
18
19 Try{
20Write-Host "Get user info for user: $Upn" -ForegroundColor Magenta
21 $User = Get-MsolUser -UserPrincipalName $Upn -ErrorAction Stop -ErrorVariable GetUserErr | Select UserPrincipalName, LastDirSyncTime, LastPasswordChangeTimestamp
22}Catch{
23 $Status = $GetUserErr[0].ErrorRecord.Exception.Message.ToString()
24Write-Host "Error: $Status" -ForegroundColor Red
25}
26If($Status -eq $null){
27Write-Host "Checking If User $Upn Syncs With AD" -ForegroundColor Magenta
28if($User.LastDirSyncTime -eq $null){
29Write-Host "Resetting Password for $Upn" -ForegroundColor Green
30 Try{
31 $NewPw = Set-MsolUserPassword -UserPrincipalName $Upn -ForceChangePassword:$true -ErrorAction Stop -ErrorVariable SetPwErr
32 $Status = 'Success'
33}Catch{
34 $Status = $SetPwErr[0].ErrorRecord.Exception.Message.ToString()
35Write-Host "Error: $Status" -ForegroundColor Red
36}
37}
38Else{
39Write-Host "Skipping User, $Upn Currently Syncs With AD" -ForegroundColor Yellow
40 $Status = 'Synced With AD, Skipped'
41}
42}
43 $ResultsObj = New-Object PSObject
44Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'UPN' -Value $Upn
45Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'NewPw' -Value $NewPw
46Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'Status' -Value $Status
47 $Results += $ResultsObj
48}
49
50Write-Host "Exporting to CSV at path: $CsvOutputPath" -ForegroundColor Green
51
52 $Results | Export-Csv -Path $CsvOutputPath -NoTypeInformation -Force
53 }
#6 Search For Suspicious Inbox and Forwarding Rules
Next, we need to search for suspicious inbox and forwarding rules. Usually, when an account is compromised, there are inbox rules the hacker creates to delete, move, and/or forward emails.
The script below is going to help us find those rules and then export them to a CSV. From there, you will need to review the CSV report, delete rows that contain safe inbox rules and leave the rows that contain suspicious rules.
Suspicious markers include:
- An inbox rule creation date showing that the rule was recently created
- Similarly named inbox rules with random strings, which usually indicate that they were created by a bot and not by a human
- Rules that delete emails
- Rules that forward the email to external email addresses
Thereafter, save that CSV to ensure that it only contains rows with the problematic rules. From there, we will import the CSV into the second script below and run it, which will delete those inbox rules.
Function Get-SuspiciousRules{
[CmdletBinding()]
Param(
[Parameter(Position=0,mandatory=$true)]
[string]$CsvOutPath
)
Write-Host "Getting Active User Mailboxes" -ForegroundColor Green
$users = Get-Mailbox -ResultSize Unlimited -Filter {(RecipientTypeDetails -eq "UserMailbox") -and (IsMailboxEnabled -eq $true)}
$results = @()
$i = 0
foreach($user in $users){
$i++
Write-Progress `
-Activity "Going Through Mailboxes....." `
-Status $i/$($Users.count) `
-CurrentOperation "Current Mailbox: $($User.UserPrincipalName)" `
-PercentComplete (($i / $Users.Count) * 100) `
-Id 1
Write-Host ("`nCurrent Mailbox: $($User.UserPrincipalName) " + ' | ' + "$i/$($Users.Count)") -ForegroundColor Cyan
Write-Host "Retrieving Rules for $($User.UserPrincipalName)" -ForegroundColor Green
$rules = $null
$rules = Get-InboxRule -Mailbox $($User.UserPrincipalName) | ? `
{($_.Enabled -eq $true) -and ($_.ForwardTo -ne $null -or $_.ForwardAsAttachmentTo -ne $null -or $_.RedirectTo -ne $null -or $_.DeleteMessage -eq $true)}
If($rules -ne $null){
Write-Host ("Total Count of Rules for $($User.UserPrincipalName): " + "$($rules.count)") -ForegroundColor Yellow
$j = 0
foreach($rule in $rules){
$j++
Write-Progress `
-Activity "Retrieving Rules for $($User.UserPrincipalName)" `
-Status "$j/$($Rules.count)" `
-CurrentOperation "Current Rule: $($Rule.Name)" `
-PercentComplete (($j / $Rules.Count) * 100) `
-Id 2
Write-Host "Rule $j/$($rules.count)" -ForegroundColor Magenta
$ResultsObj = New-Object PSObject
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'User' -Value $user.userprincipalname
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'RuleName' -Value $rule.Name
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'Identity' -Value $rule.Identity
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'Desc' -Value $rule.Description
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'Enabled' -Value $rule.Enabled
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'FwdTo' -Value $rule.ForwardTo
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'FwdAsAtchTo' -Value $rule.ForwardAsAttachmentTo
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'MoveToFolder' -Value $rule.MoveToFolder
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'CopyToFolder' -Value $rule.CopyToFolder
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'DeleteMessage' -Value $rule.DeleteMessage
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'MarkAsRead' -Value $rule.MarkAsRead
Add-Member -InputObject $ResultsObj -MemberType NoteProperty -Name 'RedirectTo' -Value $rule.RedirectTo
$Results += $ResultsObj
}
Write-Progress -Id 2 -Completed -PercentComplete 100 -Status "Complete" -Activity "Complete"
}
Else{
Write-Host "No Rules found for $($User.UserPrincipalName)" -ForegroundColor DarkYellow
}
}
$results | Export-Csv -Path $CsvOutPath -Force -NoTypeInformation
}
Function Delete-SuspiciousRules{
[CmdletBinding()]
Param(
[Parameter(Position=0,mandatory=$true)]
[string]$CsvImportPath
)
$CsvRules = Import-CSV $CsvImportPath
$k = 0
Foreach($rule in $CsvRules){
$k++
Write-Progress `
-Activity "Deleting Rule for $($rule.User)" `
-Status "$k/$($CsvRules.count)" `
-CurrentOperation "Current Rule: $($Rule.RuleName)" `
-PercentComplete (($k / $CsvRules.Count) * 100) `
-Id 3
Write-Host "`nRule $k/$($rules.count)" -ForegroundColor Magenta
Write-Host "Deleting $($rule.RuleName) for: $($rule.User)" -ForegroundColor Green
Remove-InboxRule -Identity $rule.Identity -Confirm:$false
}
}
#7 Alert Recipients of Emails From Hacked Accounts
This is really just for good measure, but I recommend reaching out to the recipients of any malicious emails sent from your organization’s account that were hacked. Simply run a compliance search for those accounts for anything sent in the timespan of the hack.
After you download and go through the results, gather a list of recipients and send them an email notification about any suspicious emails from accounts within your organization within a given timespan. Warn users not to click any links, open attachments, and so on. Also, send a notification to the IT department of the given company.
#8 Enable MFA for Hacked Accounts
I strongly recommend enabling MFA for the hacked accounts. It might not be convenient for the end-user, but since we’ve established that they are risky and perhaps careless when it comes to sifting through their emails, it’s a necessary action.
If it’s just a few users, it shouldn’t take more than five minutes to:
- Call them and confirm they have access to their account (after you reset their password)
- While on the phone, enable MFA
- Sign them out
- Have them try to log back in and walk through the MFA prompts thereafter
- Explain that they will get prompted to verify their identity if their sign-in attempt is determined to be from an untrusted device.
Once you get them signed-in on their computer, make sure their Outlook Desktop application and their Outlook web app are signed in as well, and also make sure they are able to sign-in and verify if needed on their mobile devices.
To enable MFA, sign-in as an administrator account into Office 365 (delegated partner credentials won’t work for this). On the left navigation pane, go to Settings > Services & Add-ins > Click on “Azure multi-factor authentication” > Click on “Manage multi-factor authentication” on the right window-pane that appears.
From there, you will see a list of users. If it’s just a few users, enable MFA one-by-one; otherwise, you will need to click the Bulk Update button, and upload a CSV for the user accounts to which you would like to apply the change. There is a link there to download a sample CSV to help set up the CSV with the appropriate column headers.
Conclusion
I hope this article provided some direction on phishing response actions to perform when some accounts have been compromised.
Please feel free to comment below with questions, suggestions, and feedback.
Learn about:
- Centralized management
- Bring-your-own storage approach
- Flexible pricing, and more
