• Enable Multi-Factor Authentication (MFA) for your Administrator accounts
• Reduce the number of Administrator accounts to less than five
• Evaluate your Microsoft Secure Score and Microsoft Identity Score to identify additional security settings to implement
• Implement Advanced Threat Protection (ATP). Define all three policies: Anti-Phishing, Safe-Links, Safe-Attachments. If you do not currently own ATP, consider a 30 day trial.
• Discover who is attacking your Office 365 User Identities
• Review logs for Legacy Authentication activity
• Review reports for SPAM campaigns and identify the most targeted users

• Deploy the Outlook Plug-In to Report Suspicious Email
• Block Legacy Authentication with a Conditional Access Policy
• Turn on Password Hash Sync
• Import Azure AD Logs into your SIEM systems

• Communicate to users about the new Outlook Plug-In to Report Suspicious Email
• Begin designing a new user security training program
• Initiate Brute Force and Password Spray attack against your own users
• Initiate a simulated spear phishing attack
• Modernize your password policy with Azure Active Directory Password Protection
• Implement the Azure Geo-IP filter policy

• Enable user risk policy
• Enable sign-in risk policy
• Review application consent permissions and prevent future permissions
• Implement Windows Hello
• Deploy Microsoft Smart Screen

1. Logon to https://securescore.microsoft.com. This is a direct link to your Microsoft Secure Score. This area can also be accessed using the Security and Compliance Center in the Microsoft Office 365 Portal.
2. When logged in, you can see the overall security score of your organization…front and center! This is a screen capture of my demonstration tenant where my score is 188/716. While this may seem bad, it is far better than the average score across all cloud tenants that was, as of November 19, 2018, a value of 33.
   
3. As you scroll down, you will find a number of actions in the queue to consider doing.
   
4. Expanding each of the actions listed will provide a wealth of information as shown below when I expanded the first item: Require MFA for Azure AD privileged roles.
   
5. Above the list of action items is a slider bar that will allow you to help define a target score. Remember there are a lot of action items you may choose, but do not feel compelled to take all actions. Evaluate each item and implement them based on what is appropriate for your organization.
   
6. At the top of the screen are two tabs, Dashboard and Score Analyzer. Using the Score Analyzer tab you can track your progress over a period of time. This information can be invaluable to provide to a security team or auditor of your environment. Consider using the Export option in the upper right of the screen as well.
   Microsoft Identity Secure Score The Microsoft Secure Score area above includes information available in this next section called the Identity Secure Score. You can evaluate the Identity Score in detail using the steps below. More information on Identity Secure Score is available here.
7. To access your Identity Secure Score, logon to https://portal.azure.com
8. Click Azure Active Directory
   
9. Under the Security section, click Identity Secure Score (Preview(as of November 2018)).
   
10. In the Identity Secure Score area, you will find your calculated score, comparison to other tenants in your industry, the trend of your score over the last 90 days, and a list of Improvement Actions to consider implementing.
    

1. Clicking on an action in the Improvement Action list will open a new blade of very detailed information.
   

1. Using the download option in the Improvement Action will generate a CSV file that can be used for additional data point tracking and sorting. Below is a sample download of the demonstration tenant information.
   

1. To change the industry type used to evaluate your organization's Identity Secure Score:
   1. Click on the Change Industry option
      
   2. The Security and Compliance Center will now load and log you in.
   3. Locate the Service Assurance section. Then click on Update Industry and Geography Settings.
      
   4. In this section choose the Region and Industry you would like to be compared against.
      
   5. Click Save when complete. Then refresh your Identity Secure Score area as well as the Microsoft Secure Score area.

• March 2017 - Fancy Bear Employs OAuth Phishing Attack on US Elections
• April 2017 - Russian Hackers Allegedly use OAuth in Attempts to Interfere with the French Election
• May 2017 - Fake Google Docs OAuth
• November 2017 - Ocean Lotus Intel Gathering Attack
• January 2018 - Kevin Mitnick Proof of Concept OAuth Cloud Ransomware
• March 2018 - Cambridge Analytica Data Scandal Exposed

1. In your user education training about phishing emails, you can include this potential attack as well.
2. Audit the consent permitted for all applications in your environment.
   1. Using the Azure Portal to discover apps approved by users and administrators
   2. Using a PowerShell script by Phillippe Signoret (link below)
   3. Use Microsoft Cloud App Security (MCAS)
3. You can block consent for future applications from being permitted by users. This will become an administrator only function.

Audit Method One: PowerShell Script

A PowerShell script is available from Philippe Signoret in GitHub that can be used to export all of the delegated permissions and application permissions in an easy to sort format. Use the link above to download and execute the script for application permission discovery.

Audit Method Two: Microsoft Cloud Application Security (MCAS)

Using MCAS, review the applications with permissions already in your environment. To access this area, follow the steps below. This instruction set assumes you have licensing for MCAS.

1. Logon to https://portal.cloudappsecurity.com with a global administrator account
2. Click on the Investigate option on the left (the eye glasses icon).
3. Select App Permissions
   
4. In App Permissions, you will now see all of the applications that are currently authorized for integration with your environment. You may have none, some, or a group of items listed. For each item, the Authorized by column displays which user authorized each item, what level of permissions are provided (High, Med, Low) The options are available to Approve or Deny each application.
   

Audit Method Three: Azure Graph Explorer - Permissions

Using this method, logon to the Azure Portal to discover which apps have been granted permissions by users - sometimes on behalf of your organization. The Azure Graph Explorer was recently talked about at Microsoft Ignite in session BRK3251.

1. Logon to https://portal.azure.com
2. Select All Services
   
3. In the All Services search field, enter the word Enterprise. The results will be shown below.
   
4. Click on the Enterprise Applications item now displayed.
5. Under Application Type, select the option for All Applications. Then make sure Any is defined for Application Status and Application Visibility.
6. In the search field, enter the word Graph and then select Apply.
7. In the search results, Graph Explorer will now be seen.
   Note: If Graph Explorer is not seen in this section, see the last section of this blog to enable it.
8. Select the Graph Explorer. You will now see the Graph Explorer - Overview.
   

1. Click on the Permissions area on the left. From here, you can review any applications granted consent by either the Admin or by Users. See the areas highlighted below to toggle the views between Admin and User Consent.
   

1. When User Consent is selected, you will be able to see any applications provided with access and most importantly, but which user. You may then reach out to users to see if they recall taking the action and why (remember, there may be a valid business reason). In the screen below, there are no applications with access granted by users. While this is a demonstration tenant, a production environment will most likely be populated with entries.
   

1. Logon to https://portal.office.com
2. Expand the Settings area.
3. Click Services & Add-Ins
4. Click Integrated Apps
   
5. Select the option to disable the policy.
   
6. Click Save to save the new setting.

1. Logon to https://portal.azure.com
2. Select All Services
   
3. In the All Services search field, enter the word Enterprise. The results will be shown below.
   
4. Click on the Enterprise Applications area shown.
5. Under Application Type, select the option for All Applications. Then make sure Any is defined for Application Status and Application Visibility.
6. In the search field, enter the word Graph and then select Apply. If Graph does not appear, you may only see a single result like shown below:
   
7. If Graph Explorer does not appear, logon to the site https://developer.microsoft.com/en-us/graph/graph-explorer. After logging in, you should be presented with a Permissions Request for Graph Explorer like the screen below.
   
8. After selected the checkbox to Consent on Behalf of Your Organization, click Accept.
9. By going back through the instructions in step 1-6 above, Graph Explorer should now be visible as in the screen below.
   
10. You may now click on Graph Explorer and start to explore the apps with consent granted by administrators or users in your organization.

1. Logon to the Microsoft Azure portal at https://portal.azure.com (you should have MFA enabled by now!)
2. Select Azure Active Directory
   

1. Click anywhere on the Sign-Ins activity graph to view detailed information.
2. By default, a column called Client App is not displayed in the Sign-In information. This data is what we are searching for. To add the Client App column, follow these steps:
   1. Click on the Columns option
      
   2. Place a check next to Client Apps in the columns option area.
      
   3. Click OK when complete.
      Note: Additional information in this list is also valuable to review such as source IP addresses that identity attacks are originating from.
3. In the Application search field, enter the word Other as highlighted below.
   
4. Click Apply to search the logs.
5. If there are any legacy authentication applications in use, it will appear under the Client App column and called Other Clients.
6. If legacy authentication clients are found, usernames and IP addresses may be used to locate and migrate the applications to one with a modern authentication method.

1. Logon to your Azure portal at https://portal.azure.com
2. Select Azure Active Directory. Then click on Conditional Access.
   
3. Click on New Policy
   
4. Name the new policy. For this example, I named the policy "Disable Legacy Email Authentication." This is also known as Legacy Auth.
   
5. Use caution when enabling any type of conditional access policy. A misconfiguration could prevent a critical business application from working or even worse, lock you as the administrator and everyone out from the environment. With this caution in mind, test this policy first in a lab environment and then on test accounts as a pilot. Below are the steps to limit the policy to only select users or a group of users.
   1. Select Users and Groups
   2. Select the option for Select Users and Groups
   3. Select Users and Groups
   4. Click Select
   5. In the Select area, I have a predefined Test Group in this demonstration environment that is now selected. This will limit this new policy to only users who are part of this group.
   Once done with testing and piloting of this new conditional access policy, plan a gradual roll-out process.
6. Next, select Conditions. Then select Client apps (preview).
   
7. As a default setting, this policy is NOT configured.
   
8. Select Yes to enable the policy and then edit it.
9. Within the policy, check only the option for Mobile apps and desktop clients. Then select Other clients in the sub-category. Do not select the other policies available in this configuration area. In the next section, we will create another policy to define options for the other categories.
   
10. To see additional information about what the Other Clients are, click on the information option. The screen below appears:
    
11. With the settings now defined, click Done in the Client apps (preview) blade and then Done in the Conditions blade.
    
12. It is now time to define the block action for Other Clients. While still in the New Policy configuration area, select Access Controls and then Grant. In the new blade, select Block Access.
    
13. With Block Access defined, click Select.
14. To complete this action, the policy must now be enabled. Click the Enable Policy option to On.
    
15. Then select Create to complete the policy setup.
    
16. The policy is now created and enabled. It will block older Microsoft Office clients and protocols including POP, IMAP, SMTP and others that includes ACS.
    Note: the policy may take 24 hours to activate.

1. Logon to https://portal.azure.com as a global administrator.
2. Click on Azure Active Directory
   
3. Click on Authentication Methods
   
4. In this screen, you can configure the custom smart lockout functions for Azure AD users. Keep in mind that these lockout threshold and durations are only for Azure AD users. Active Directory still has its own lockout and password protection policies that is in place for on-premises based users. Azure Active Directory Password Protection is in addition to this.
   
5. In the screen above, in addition to the list of passwords Microsoft is preventing by default (this default list is never exposed as to not give attackers any insight), you may enter custom passwords to block from being used. In this custom list, you may want to enter terms such as the sports teams local to your office locations, your organization's name, key project names, key products a company produces, and anything else that users in your organization may typically use. You can then test this policy by using a test user account in Azure AD.
6. Also in the screen above, notice the two settings for Windows Server Active Directory. These are for your on-premises Active Directory Domain Controllers (covered in next section). When ready, set the first option to enable password protection to Yes and then set the Mode to Audit.

1. Go do the download site to access the Domain Controller agent as well as the Protection Proxy agent. Select both for download.
   
2. On your first domain controller, open the AzureADPasswordProtectionProxy.msi file to start the installation. Click Install to initiate the installation. This will take under 30 seconds to complete.
   
3. The Installation completes within about ten seconds. Click Finish to end the installer and proceed to the next step. There is no reboot required for the proxy agent installation.
   
4. You must now register the proxy and the Active Directory Forest to communicate with Azure. These steps are done in PowerShell.
   1. Open PowerShell in Administrator mode
   2. Make sure the Azure AD password Protection Proxy agent is running by typing: get-service AzureADPasswordProtectionProxy.
      
   3. Register the proxy agent with Azure Active Directory by typing: Register-AzureADPasswordProtectionProxy. You will be prompted for credentials.
      
   4. Register the on-premesis Active Directory Forest with Azure Active Directory by entering: Register-AzureADPasswordProtectionForest. You will again be prompted for credentials.
      
   5. If needed, you may change the port the Azure AD Password Protection Proxy Service is listening on. Use instructions here if needed.
5. On the first domain controller, open the downloaded Domain Controller agent and select Install to start the installation.
   Note: A reboot will be required to complete the installation of the domain controller agent.
6. Within a few seconds, the installation is complete.
   
7. The agent installer will prompt for a reboot of the domain controller.
   
8. After the domain controller agent is installed and the domain controller has rebooted, there is no other configuration required on the servers.
9. At this point, make sure to follow the options in the Password Protection for Windows Server Active Directory below are set correctly. Select Yes to enable the Windows Server Active Directory protection and set the Mode to Audit.
   
10. Information about monitoring the domain controller agent and proxy agent is located here. Once ready, go back to the configuration in the previous step and change the Mode to Enforced.

• Perform a Brute Force Password Attack
• Perform a Password Spray Attack

1. As a global administrator with MFA enabled, logon to https://protection.office.com
2. Expand Threat Management and then click on Attack Simulator.
3. Locate the middle option called Brute Force Password (Dictionary Attack).
   
4. Click on the Launch Attack option.
5. Provide a name for the new attack and click Next.
   
6. Select several users to target or select a group of users. Names of users and groups will auto populate as you start to type them.
   
7. In the next screen, enter each password you would like to use in the attack. As you enter each password, press Enter. After each value entered, you will see a series of dots appear instead of the password just entered. You may also search for a dictionary of common passwords on the Internet to use that can then be uploaded for use. Be cautious in your search for these dictionary attacks as several I located did not appear safe for download and use.
   
8. Confirm that you are ready to start the attack and click Finish to begin.
   
9. After a few minutes, depending on how many users you are running the brute force password attack against and/or the number of passwords used, the attack details should be ready to view. On a refresh of the screen, you will find a note indicating the attack has been completed.
   Click on the option to View Report to see the results
10. We can see in the report below that two of the users I selected in this attack were found to be using weak passwords or passwords in the specific list I entered. In all fairness, for this example I entered the passwords used for a few of these users in this demonstration tenant environment (these are fictitious accounts).
    

1. As a global administrator with MFA enabled, logon to https://protection.office.com
2. Expand Threat Management and then click on Attack Simulator.
3. Locate the middle option called Password Spray Attack.
   
4. Click on the Launch Attack option.
5. Provide a name for the new password spray attack.
   
6. Enter the user names or groups of users you want to run this attack against.
   
7. Enter the password you want to use in this attack. You can only enter a single password in this attack that will then be used to logon to all the users you identified.
   
8. Click Finish to begin the attack.
9. Click on the Refresh button at the top of this screen. Notice that the attack has been completed and you are given an option to View Report.
   
10. Click on the View Report option. Note that two of the users were breached by using the password examples I provided in this example.
    

• Change a password every 30 days
• Require complexity in passwords
• Force passwords to be 9,10, or more characters in length

• The user who fell victim to the phishing email entered a username using the format used throughout your environment. The attacker now knows this format, providing a key piece of information.
• The attacker was able to harvest your user directory. He or she now knows the username and email address of everyone in your organization. Perhaps he or she knows the job titles of each person as well if that field is populated in your directory, including individuals who are managers or part of the executive leadership team. Algorithms can now be adjusted for a spear phishing attack against these high value identities with a much higher likelihood of success.

• With a directory of your users now in the hands of an attacker, names can be researched on social media sites to find out more about each person. Algorithms can then be adjusted to include passwords that may include (using our example above) your favorite animal with a combination of special characters and capitalization. If you can think of the potential password combinations, the algorithms are designed to try them as well. This type of attack can go on for weeks, months, years, but the probability of a successful password guess grows higher each day.
• With additional information learned from social media sites about your users, an attacker could determine where each user has other accounts. Although your organization may have fortified its network defenses in various ways, consider this: 'have these social media sites done the same?' An attacker could start logon attempts at these social media sites using the user email addresses discovered in the original attack and again start to guess passwords there with information now known. A successful password guess on one of those sites is now just another clue to a successful password into your organization. If an attacker successfully guessed you are using Lion42 as your password in a social media site, algorithms can then be further fine-tuned to try variants on the identities used at the primary attacker's target.

1. Maintain an 8-character minimum length requirement (and longer is not necessarily better)

2. Eliminate character-composition requirements

3. Eliminate mandatory periodic password resets for user accounts

4. Ban common passwords, to keep the most vulnerable passwords out of your system

5. Educate your users not to re-use their password for non-work-related purposes

6. Enforce registration for multi-factor authentication

7. Enable risk based multi-factor authentication challenges

• See which of your user accounts are the most heavily attacked in terms of who is trying to guess their usernames and passwords. Some user accounts, such as those for a leadership team, are often more attacked than others.
• Identify if a user account has been breached and take quick action.
• Download detailed information in a Microsoft Excel or CSV file format for data sorting.
• Sort information about where these attacks are coming from based on country location.

1. Logon to portal.azure.com as a global administrator
2. In the index of features on the left, select Azure Active Directory
3. By default, Overview will be highlighted
4. Which license do you have?
   1. In the Overview section, if you see the screen below with the text "To see sign-in data, your organization needs Azure AD Premium P1 or P2. Start free trial." then proceed to the next section to enable the 30 day trial license.
      
   2. In the Overview section, if you see the screen below with sign-in event information for your organization then you have the license needed to view the data.
      

1. In the screen above (step 4a), click on the link to Start a free Trial.
2. You now see two trial options available. One for Enterprise Mobility and Security E5 (a future blog) and second option for Azure AD Premium P2. Click on the Free Trial in Azure AD Premium P2.
   
3. In the next screen, information about the trial is displayed. After reviewing the information, click Activate.
   
4. Within several seconds, a notification of a successful activation for this trial is displayed in the upper right corner.
5. With the trial subscription now activated, in the same Azure Portal screen click on the Azure Active Directory option in the index on the left side of the screen. You will now see sign-in information for your Azure AD users in Office 365.

1. When logged in to the Azure Portal at portal.azure.com, click on Azure Active Directory in the left index area.
2. Now displayed is a summary graph of Office 365 User Sign-In information. Click directly on the summary graph to view detailed information.
   
3. We now start to see some interesting details such as the user sign-in, what application was used to sign-in, was a conditional access policy applied (future blog) and was Multi-Factor Authentication (MFA) required? In my demo tenant data below, notice my global administrator account required MFA but a user named Megan Bowen did not.
4. Depending on your organization size, there may be a great deal of logon activity to scroll through. From this screen, you can review Successful and Failed logon events by choosing the options in Sign-In Status.
5. In this view, we are still not seeing all the information available. Let's make this a bit more interesting and gather detailed information to review the points highlighted in the beginning of this blog.

1. Within the same Azure Portal view as above, click on the Download link
   
2. The detailed information downloads in a CSV format by default.
3. Open the file in Microsoft Excel. I usually start by sorting entries at the top of each column. Do this by highlighting a cell in row one where the column data heading is. Then select Sort &Filter on the Excel ribbon in the upper right. Then select Filter in the drop down options.
   
4. With a drop down filter now added for each column heading, we can start to review data logged for suspicious logon activity. Below, I set the stage a bit more for the data shown from this fictitious company.

   Scenario: As we begin to review the sign-in information, consider the scenario of your own tenant. Are you a small business who operates in one specific region, a State, a Province, etc. Perhaps you are a mid-size company or even an enterprise company where you have traveling sales people. For your organization, you will most likely know your users and where they typically operate from. Even more importantly, you will know where your organization does not operate and therefore be able to identify suspicious logon activities from regions of the world where your users would never travel to.

   The data presented in this blog is fictitious from a demonstration tenant in Office 365, but represents user logon names, applications, locations, etc. data you may see in your logs.

   The data presented here has been modified a bit for our scenario to represent a small-mid size company operating in the Maryland area of the United States.

   Note: The IP addresses in this list have been obscured, but know that you will get exact source IP addresses listed in your data. I also removed a few columns not needed for this type of data review.

5. At a first glance at this data, I see what looks like normal logon information. The sign-in information from cities in Maryland are normal, the usernames look right, there are successful logon events, etc. We even see that some users have Multi Factor Authentication (MFA) enabled while others do not.
   
6. While the information displayed so far appears normal, let's see where other logons are coming from. In my column F, I'll select the filter drop down option to display the location values in this long list. Now this starts to get interesting.

   Remember my demo tenant scenario of being a small-mid size organization in the Maryland state area. I know my users do not travel as part of their work outside of the region and while it is possible an employee or two may be traveling the world on vacation, it is not likely.

   So looking at the now sorted data, I now see attempted logon attempts from a long list of cities and countries where I shouldn't be seeing any activity from.
7. I want to research more information about these logons and will therefore go through the list of locations and deselect all of the Maryland and surrounding areas found in the list above, leaving me with mostly international locations. Now this really starts to get interesting in the list below. The frequency and widespread logon attempts from attackers attempting to access your network is now in full view.
8. In addition to understanding where logon attempts are coming from to access your organization's resources, there is additional information to review:

a.   I also want to see the Failures listed in the Sign-in Status column. In the screen capture below where we are sorted on locations other than where our organization operates, also sort on the Sign-In Status column to see where Success is located. From here, be sure to look for any Success status listed for suspicious locations. If seen, you need to assume you have a breach in your organization and take appropriate action to protect your organization - starting with the user account that appears to be breached in this report.

b.   A scan of the data will also reveal who your most attacked users are. Is it someone from your leadership team with financial approval, is it a webmaster or admin email account that has been published on the Internet, or even an info@domain.com address listed on your website? This data should be used to generate a report to the leadership team of your organization with a recommendation of actions to take (such as enable MFA for all users).

Part 3: Deploy Multi Factor Authentication (MFA)

Part 5: Define Country and Region Logon Restrictions for Office 365 and Azure Services

This data is being presented as part of a 30 day trial license to Azure Active Directory Premium P2 for some readers. If on the trial, consider subscribing to this license to periodically review this data and further protect all of your users. The data collected in this report using the P2 license is just one of many features available with this subscription as described in this site.

1. Logon to https://protection.office.com as a global administrator account.
2. On the left side of the screen, click Reports to expand the list of reports.
3. Click Dashboard
4. Here, we can see several ATP reports, malware detection reports, SPAM detection reports, etc. to choose from.
5. The reports I find most useful and insightful in the attacks on an environment are:
   • Threat Protection Status
   • Malware Detections
   • ATP File Types
   • SPAM Detections
   • Spoof Mail

1. As an example report to schedule, click on the Advanced Threat Protection File Types Report.
2. Click the option to +Create Schedule
   
3. You are now presented with a standard report schedule that may be accepted as is or may be customized. To customize the schedule, under Options, select Customize Schedule.
   
4. Using the options presented, you can adjust the scheduled report name, frequency of delivery, email recipients (to you and/or a security monitoring team), etc. I suggest you choose only a few key reports for delivery. Scheduling any more than a few reports will just become noise in your Inbox and you will not make the time to review them.
5. To review and modify all scheduled reports, click the option to Manage Schedules under the Reports section of the Security & Compliance area. Below, you can see one of the sample report I have scheduled for delivery.