Every Question Tells a Story – Mitigating Ransomware Using the Rapid Cyberattack Assessment Tool: Part 2

Published on September 10, 2018 by Dave BranscomeLeave a comment

In my previous post, I explained how to prepare your environment to run the Rapid Cyberattack Assessment tool, and I told you that the questions in the tool would tell you a story.

https://blogs.technet.microsoft.com/cloudyhappypeople/2018/09/10/every-question-tells-a-story-mitigating-ransomware-using-the-rapid-cyberattack-assessment-tool-part-1/

So, let’s get started with the storytelling, shall we?

Survey Mode or Full Assessment?

Once you start the tool, you are asked if you want to run the tool in Survey Only mode, or in the Full mode.

What’s the difference?

Survey mode simply asks a set of questions that relate to your environment and then provide you with some guidance on what you should look at to start protecting against ransomware.
Full mode includes the survey questions, but it also runs a technical assessment against the machines in your environment to identify specific vulnerabilities.

Thus, survey mode is much quicker – but provides you with less information about the actual machine sin your environment.

This is the mode we will use for the tool.

The next page just outlines the requirements for running the tool, which we discussed previously.

Now comes the fun part…the questions.

The Story-Telling Questions

The first question relates to patching.

Question:

“How long does it take to deploy critical security updates to all (99%+) Windows operating systems?”

Why do we ask?

When Petya hit in the summer of 2017, some of the worst-hit organizations were those who had failed to apply one patch to their Windows operating systems. The “Eternal Blue” exploit, which takes advantage of how SMBv1 handles specific types of messages, had been patched three months before Petya made headlines.

(https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2017/ms17-010)

If organizations had applied the patches to their systems within 30 days, it’s possible that they could have eliminated their exposure to that exploit.

————————————————————

Question:

How long does it take to deploy critical security updates to all (99%+) deployed software (operating systems, applications, middleware, routers/switches/devices, etc.)?

Why do we ask?

Petya didn’t specifically leverage a weakness in, for example, a switch’s operating system. But it should go without saying that any vulnerability that exists on ANY piece of networking equipment or application or middleware is a weakness in the overall chain. If, for example, an adversary can compromise a switch and gain administrative control over all the traffic flowing between machines, they would then potentially have the ability to capture passwords and other critical information, which then allows them to make their next move.

———————————————

Question:

What strategy do you use to mitigate risk of Windows operating systems that cannot be updated and patched?

Why do we ask?

Unfortunately, some of the organizations that were most severely compromised by Petya/NotPetya/WannaCry had been running versions of Windows that have LONG been unsupported. There may genuinely be reasons why they haven’t been updated. Perhaps they are running software from a third-party that has not been tested against newer operating system versions. Maybe the third-party software vendor went out of business and no suitable replacement has been found. Regardless of the reason why the legacy operating systems exist, the key thing that needs to be addressed is “how do we reduce the risk of keeping these systems around?”. If they cannot be upgraded, can they be isolated on a network that isn’t connected to the Internet, and that separates them from the production network? Remember, if one machine can be compromised, it presents a potential threat to every machine on the network.

———————————————————-

Now the questions start to get a bit more complex….

Question:

What is your strategy on staying current with technology?

Why do we ask?

This question is really asking, “Are you taking advantage of every improvement in security – whether in the cloud, in Microsoft products, on MacOS, the various flavors of Linux, mobile devices, etc.?”

It’s probably safe to say that most of the major software and hardware vendors do their level best to improve the security posture of their products with every new release – whether it’s adding facial recognition, or stronger encryption, or even just addressing vulnerabilities that found their way into previous versions of code. If your user base is running primarily on Windows 7 or *gasp* Windows XP, there are, without any question, vulnerabilities that they are exposed to. Windows XP has, of course, reached its end-of-life, so any exploits identified for Windows XP are no longer being patched by Microsoft. That means these vulnerabilities will exist on your network for as long as those machines exist on your network.

That’s a little scary.

The same is true of mobile devices, Mac OS, Linux machines, and so on. Unless they are updated, they will continue to be targeted by the bad guys using common, well-known exploits.

Don’t gamble with your network.

Stay current to the extent that you can do so.

——————————————————-

Question:

Which of the following is true about your disaster recovery program?

Why do we ask?

This is an interesting question. I’ve worked with a couple hundred Microsoft customers over the years, and it’s always interesting to hear exactly how each customer defines their disaster recovery strategy. Most customers have a regular backup process that backs up critical services and applications every day, or every couple hours. Most of those customers probably ship their backup tapes to an offsite tape storage facility for safekeeping in the event of a disaster. Many organizations will say they regularly validate the backups – when what they might mean is “I was able to restore Bob’s Excel file from two weeks ago, so I know the backup tapes are good.” Many organizations also perform some form of highly controlled DR testing yearly or quarterly.

But when you think about what Petya did, are those measures adequate? Imagine every one of your machines completely inoperable. You can recall all the backup tapes you’ve ever created, but your BACKUP SERVER is encrypted by ransomware. Now what? And even if it wasn’t, you can’t authenticate to anything because your domain controllers are encrypted. You can’t even perform name resolution because your DNS servers are encrypted. You could try to send an email from Office 365, but if you have ADFS set up, the authentication for Office 365 is happening on-premises…. against the domain controllers….which are encrypted by ransomware. This is the situation that some organizations faced.

Very few customers who were hit by Petya were prepared for a scenario where EVERYTHING was inoperable, all at the same time. Many were relegated to communicating via text message and WhatsApp because every other communication channel was inaccessible.

——————————————————

Question:

Which of the following measures have you implemented to mitigate against credential theft attacks?

Why do we ask?

Here’s the sad truth about Petya. There were organizations that had 97% (or more) of their workstations patched against the Eternal Blue exploit that we talked about earlier. But Petya didn’t just use one attack vector. Even if only one of the machines on a network of 5,000 machines was unpatched – that was enough of a wedge for Petya to gain a foothold. The next thing it did was attempt to laterally traverse from machine to machine using the local administrator credentials it was able to harvest from the unpatched machine. It would then attempt to use those credentials to connect to all the other machines on its subnet. So even if those machines were patched, if the administrator passwords were the same on those machines, those machines were toast.

Now think about that. How many organizations use a single administrator account and password on every desktop/laptop on the network? Based on what I’ve seen – it’s probably a sizable number. So even if those IT admins are very conscientious about patching, if they use the same local administrator password on every machine, a compromise of one machine is effectively a compromise of ALL the machines.

But how do you manage different passwords on thousands of different machines on a network?

We’ll discuss this quandary in a moment.

——————————————————

Question:

Which of the following measures have you implemented to protect privileged accounts and credentials?

Why do we ask?

It should be obvious that protecting your high-value credentials is important, but let’s talk about the measures you can choose from in the list:

Create separate accounts for privileged activities (vs. standard accounts for email/browsing, etc.): Many organizations have learned this lesson and are good about creating separate sets of credentials for administrative activities and a lower-privileged account for everyday IT worker stuff like checking email, creating documents and surfing the web.
Enforce multi-factor authentication on all privileged accounts: I’m happy to say I’m seeing many more organizations using multifactor authentication for highly-privileged accounts, whether it’s a token, or a phone-based tool like Microsoft Authenticator, or whatever. This is great to see, and I encourage every organization to start looking into MFA. In fact, Office 365 and Azure have MFA capabilities built right in – you just need to turn them on.
All privileged users are prevented from using email and browsing the internet: The key word here is I would venture to say that most organizations advise their admins not to use their admin accounts for browsing the web or checking email. But what if you are fixing a problem with a server and Microsoft has a hotfix that you need to download. Can’t you just this once…..? The answer is “no”. Admin accounts should be prevented from browsing the internet. Period. Nothing good can come of browsing the wild and wooly internet with an admin account. It’s like walking in a seedy part of the city at night with $100 bills hanging out of your pocket.
Restrict Tier 0 privileged accounts to only logon on Tier 0 servers and trusted workstations (such as PAWs): This is one of the most critical parts of securing administrative access. A core principle for securing administrative access is understanding that if admin A is logged into Workstation A, and he then makes an RDP connection to Server B, then the workstation is a “security dependency” of the server. Put simply, the security of Server B depends upon the security of Workstation A.

If administrative credentials can be harvested from Workstation A due to lax security controls (for example, using pass-the-hash or pass-the-ticket techniques) then the security of Server B is jeopardized. Therefore, controlling privileged access requires that Workstation A be at the same security level as the machines it is administering. Microsoft’s Privileged Access Workstation (PAWs) guidance can help you understand how to accomplish this.

Microsoft IT enforces the use of Privileged Access Workstations extensively to manage our own privileged assets.

Take the time to read more about Privileged Access Workstations here: http://aka.ms/cyberpaw

——————————————-

Question:

Which of the following risk mitigation measures have you implemented to protect Tier 0 assets (Domain Controllers, Domain Administrators) in your environment?

Why do we ask?

The concept of “standing administrative privilege” is one that carries a significant element of risk today. It’s a much better practice to leverage “Just In Time” privileges. This means that the administrator requests, and is granted, the access they need AT THE TIME THEY NEED IT. When the task they are performing is complete, the privilege is revoked. When they need the privilege again, they need to request the access again. This is also good for auditing purposes.

A corollary to this idea is “Just Enough Admin” access. In this scenario, an admin is given THE LEVEL OF PERMISSIONS THAT THEY NEED, AND NO MORE. In other words, if you need to perform DNS management tasks on a Windows server, do you NEED Domain Administrator credentials? No, there is a DNS Administrator RBAC group that can be leveraged to grant someone the needed level of permissions.

Combine “Just Enough Admin” with “Just-In-Time” access, and you significantly reduce the chance of administrative credentials being exposed on your network.

More info here:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models

———————————————————

Question:

Which of the following is true with regards to your partners, vendors and outsources?

Why do we ask?

This is related to one of the more fascinating aspects of the Petya attack.

MeDoc is a company based in Ukraine that makes financial accounting software used by many business and organizations in Ukraine. The Petya attack began when a threat actor compromised the MeDoc application and inserted the Petya ransomware payload into one of the update packages. When the MeDoc customers received their next update, they also received the Petya ransomware. From there, Petya started looking for machines that were vulnerable to the Eternal Blue exploit. Once it found a vulnerable machine, it began attempting the lateral traversal attacks using local administrator privileges that we talked about earlier.

You see how the whole picture is starting to come together? Every question tells a story!

The point behind this question is this: in today’s world, it isn’t enough to simply consider your own security controls and processes. You also must consider the security practices of the vendors and partners you’re doing business with and understand how THEY react to attacks or compromises, because their threats could very well be your threats someday.

———————————————————–

Question:

Which measures do you have deployed to protect your environment from malware?

Why do we ask?

Any IT admin worth their paycheck has for years been fighting the good fight against things like malware and spam.

But there’s a little more to the question than simply asking if you have an anti-spam and anti-malware component to your network management strategy. The question is also asking “how well does your anti-malware solution protect against the more sophisticated attacks?”

Consider this: from the time that no machines were infected by Petya to the time that tens of thousands of machines were infected by Petya was only about 3 ½ HOURS. That is simply not enough time for an antivirus vendor to reverse engineer the malware, develop a signature, and get it pushed down to their customers. The only real way an antimalware solution can be effective at that scale is if it gets telemetry from millions of endpoints, can detect anomalies using machine learning within SECONDS and take action to block across the world.

For an account of how Windows Defender did exactly that against the DoFoil crypto mining malware, read this story:

https://cloudblogs.microsoft.com/microsoftsecure/2018/03/07/behavior-monitoring-combined-with-machine-learning-spoils-a-massive-dofoil-coin-mining-campaign/

———————————————————

Question:

Which of the following legacy protocols have you disabled support for in the enterprise?

Why do we ask?

As mentioned earlier in this article, the Petya attack exploited a vulnerability in the SMB V1 protocol that was nicknamed Eternal Blue. SMB (also known as CIFS) is a protocol designed to allow shared access to files, printers and other types of communication between machines on a Windows network.

However, SMB v1, as well as LanMan and NTLM v1 authentication have vulnerabilities that make them potential security risks.

Remember, any protocol that isn’t being used should be disabled or removed. If a protocol is still being used and cannot be removed, at the very least, you need to ensure it is patched when needed.

Learn how to detect use of SMB and remove it from your Windows network here:

https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and

——————————————————–

Question:

How do you manage risk from excessive permissions to unstructured data (files on file shares, SharePoint, etc..)?

Why do we ask?

Indeed, why does having knowledge of the permissions on a file share have anything to do with a ransomware attack? Again, there’s a key word here: excessive permissions.

For example, one very common mistake is to assign permissions to the “Everyone” group on a file share. The problem, as you no doubt are aware, is that the Everyone group does not simply mean “everyone in my company”. For that purpose, the “Authenticated Users” group is what you are likely thinking of, since that includes anyone who has logged in with a username and password. However, the Everyone group includes Authenticated Users – but it also includes any user in non-password protected groups such as Guest or Local Service. That’s a MUCH broader group of user accounts, and its possible that some of those accounts are being exploited by people who may be trying to do bad things to your network.

The more people or services there are that have permissions on your network, the greater the chances that one of them will inadvertently (or intentionally) do something bad. It’s all about reducing your risk.

Therefore, a best practice is to perform an audit of your file shares and remove any excessive permissions. This is a good practice to perform anyway, since users change roles and may have permissions to things that they no longer need (such as if an HR person moves into a Marketing role).

—————

Well, that’s a lot of questions, huh?

In my final post, I’ll show you the last couple steps in using the tool and then walk through the findings.

https://blogs.technet.microsoft.com/cloudyhappypeople/2018/09/10/every-question-tells-a-story-mitigating-ransomware-using-the-rapid-cyberattack-assessment-tool-part-3/

Every Question Tells a Story – Mitigating Ransomware Using the Rapid Cyberattack Assessment Tool: Part 1

Published on September 10, 2018 by Dave BranscomeLeave a comment

They say that a picture is worth 1,000 words.

But in some cases, the questions that you ask can also help tell a very interesting story.

Let me explain.

All of us are familiar with the devastating effects of ransomware that we saw last year in the WannaCry, Petya, NotPetya, Locky and SamSam ransomware attacks. We read the stories of the massive financial impact these attacks had on their victims, and we can only imagine the stress that the individuals in the IT departments of the impacted organizations went through trying to recover.

You may know that Microsoft has created a tool called the Rapid Cyberattack Assessment. The intent of the tool is to help an organization understand the potential vulnerabilities and exposures they have to ransomware attacks so that they can take steps to keep from being the next victim.

But like I said – every question tells a story – and in this tool there are many questions that an IT admin needs to ask himself or herself, and there’s a story behind each of these questions that helps make the tool’s value evident.

Let’s take a look at the tool and as we go through the tool I’ll try to give you the story behind each question.

Preparing the Environment

First, let’s download the tool itself.

It’s a free download from Microsoft, located here:

https://www.microsoft.com/en-us/download/details.aspx?id=56034

It’s important to download both the executable (RCA.exe) and the requirements document. The requirements document is also important, because if you don’t set up the tool correctly as well as the target machines, you likely won’t get some information that’s very valuable.

Conditions

First of all, you need to be aware that the Rapid Cyberattack Assessment tool runs in an Active Directory environment, and against Windows machines only. Any machines that you target with the tool must be part of an Active Directory domain. Additionally, the tool is limited in scope to 500 machines.

What should you do if your environment is larger than that?

There are really two simple options:

Assess your entire environment in 500 machine chunks. Run the tool against a specific OU or group of OU’s that total no more than 500 machines. You can also just create lists (maybe exported from a spreadsheet) and use that as input for the tool. This method will definitely take a little bit of time and it won’t give you a single, comprehensive report view, either.
Take sample machines from a number of different departments and run the tool against them. With this method, you would take (as an example) 50 machines from HR, 50 machines from Finance, 50 machines from Sales, etc…and run the tool against them. It doesn’t capture data on every single machine in the environment, but the tool is designed to give you an idea of where your exposures lie, and that would most likely be revealed in even a random sampling of machines. You can reasonably assume that any vulnerabilities identified in that subset of machines likely exists elsewhere in the environment as well.

Personally, if I was running the tool in my own environment and we had more than 500 machines, I would choose the second option. It gives me a rough idea of the issues I have to resolve and helps me prioritize them. If my environment has more than 500 machines, I’m probably managing them with some sort of automation tool anyway (like System Center Configuration Manager), so I don’t have to know exactly how each machine is configured. I’ll just define what the standard should be and push out that configuration.

Hardware and Software

Installing the Rapid Cyberattack Assessment tool itself isn’t hard at all. You simply run the RCA.exe executable. There aren’t any options or choices to make other than agreeing to the license terms. Likewise, the machine you run the tool from doesn’t have a lot of requirements. It should be:

Server-class or high-end workstation running Windows 7/8/10 or Windows Server 2008 R2/2012/2012 R2/2016.
It’s preferable to have a machine with 16 GB+ of RAM, a 2 GHz+ processor and at least 5 GB disk space.
The machine should be joined to the Active Directory domain you will be assessing.
Microsoft .NET Framework 4.0 must be installed
Optionally, you may want Word, PowerPoint and Excel installed to view the reports. But you can also just export the reports and view them on a machine that has Office installed already.

Account Rights

The service account you use to run the tool needs to be a domain user who has local administrator permissions to all the machines within the scope of the assessment. The account should also have read access to the Active Directory forest that the in-scope computers are joined to.

Network Access

The machines you are trying to assess obviously must be reachable by the assessing machine. Therefore, there must be unrestricted access from the tools machine to any of the in-scope domain joined machines. By “unrestricted access” we mean you should make sure there are no firewall rules or router ACLs that would block access to any of the following protocols and services:

Remote Registry
Windows Management Instrumentation (WMI)
Default admin shares (C$, D$, IPC$)

If you are using Windows Advanced Firewall on the in-scope machines, you may need to adjust the firewall to allow the assessment tool to run.

You can configure this using a Group Policy targeted at the in-scope machines. To do this, follow these steps.

Use an existing Group Policy object or create a new one using the Group Policy Management Tool.
Expand the Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/Windows Firewall with Advanced Security/Inbound Rules
Check the Predefined:radio button and select Windows Management Instrumentation from the drop-down list. Click
Check the WMI rules for the Domain Profile. Click Next
Check the Allow the Connectionradio button and click Finish to exit and save the new rule.
Make sure the Group Policy Object is applied to the relevant computers using the Group Policy Management Tool

You would then do the same thing for: Allow file and Print sharing exceptions

For the Remote Registry Service, you want to set the service to Automatic startup for the duration of the assessment.

Open the Group Policy editor and the GPO you want to edit.
Expand Computer Configuration > Policies > Windows Settings > Security Settings > System Services
Find the Remote Registry item and change the Service startup mode to Automatic
Reboot the clients to apply the policy

That should be enough to get you started.

In the next post, I’ll walk you through the survey questions in the Rapid Cyberattack Assessment tool.

https://blogs.technet.microsoft.com/cloudyhappypeople/2018/09/10/every-question-tells-a-story-mitigating-ransomware-using-the-rapid-cyberattack-assessment-tool-part-2/

I think you’ll find the stories revealed by the questions to be quite interesting.

Are You Following Teams Tuesdays?

Published on August 14, 2018 by Dave BranscomeLeave a comment

Microsoft Teams has proven to be one of the biggest product releases of FY18 for Microsoft, with over 200,000 customers rolling it out within just a year!

If your organization hasn’t yet rolled out Teams, or if you are in the middle of planning your deployment, be sure to check out the Microsoft Teams webinar series, being delivered by the One Commercial Partner Modern Workplace team of architects.

This is what’s on the agenda for the Teams Tuesday webinars for the next few months!

August 21, 2018

Using Automation to Provision Teams, Groups and Modern Communication Sites

In this webinar, we’ll provide you with guidance on how you can leverage automation to standardize, secure and simplify your Microsoft Teams rollout.

August 28, 2018

Understanding the Microsoft Teams Free Version

The new free version of Microsoft Teams raises a lot of questions for partners and customers alike. In this session, we’ll walk you through the limitations and use case scenarios for the freemium version of Teams and help you articulate the value of the full version.

September 4, 2018

Quality Management for Microsoft Teams

How do you prepare you network for the increased audio and video traffic that comes along with a Microsoft Teams deployment? And then once you have it deployed, how do you validate the quality on an ongoing basis? Join Andy McLaughlin in this session to learn the tricks of the trade!

September 18, 2018

Upgrade and Interop with SfB

There is a lot of confusion around the upgrade and interop story with Skype for Business Online and Microsoft Teams? How will it work? What are the caveats? What will partners need to do to transition customers? JoAnn Boxrud will help clear up the cobwebs in this webinar.

October 2, 2018

Managing Microsoft Teams Effectively

One of the great things about Microsoft Teams is that, once it takes hold in an environment, it spreads virally. As a partner, you may be asked to help manage this growth in a way that allows an organization to maintain control over data leakage, limit the use of guest access, standardize the way Teams are deployed, and so on. Robert Gates will provide tips form the pros in this webcast.

October 9, 2018

Planning for User adoption and Customer Success with Microsoft Teams

There’s much to consider when deploying Microsoft Teams. Join us for a discussion about what you can do today to help customer Teams deployments go smoothly. We provide the latest in guidance and outline the building blocks required to help make all of your Microsoft Teams customer deployments a success.

October 16, 2018

Deep Dive into Direct Routing

Direct Routing is one of the new capabilities in Teams to support Voice. What implementation options exist for Direct Routing? How do you configure Direct Routing? What are the requirements? Find out in this session.

October 23, 2018

Understanding Guest Access in Microsoft Teams

Guest Access in Microsoft Teams is one of the most important features in enabling collaboration between an organization and its partners, vendors and affiliates. What needs to be done to enable Guest Access? What are the limitations on what a guest can do? How do i audit guest access? These are some of the questions that will be covered in this webinar with Kevin Martins.

Look interesting? Then sign up here!

https://msuspartner.eventbuilder.com/?landingpageid=dst1ny

There are also lots of recorded webcasts that you can go back and review at your leisure.

Hope to see you on the next Teams Tuesday!

Leverage the Microsoft Graph with Azure Active Directory Identity Protection to Identify Network Threats

Published on April 11, 2018 by Dave Branscome1 Comment

What is Azure Active Directory Identity Protection?

Azure Active Directory Identity Protection is a feature built into the Azure AD Premium P2 license. The P2 SKU is important if you want to configure SharePoint Limited Access, CAS Proxy, or perform actions related to identity protection or control of privileged identities. The Azure AD Premium P2 (AADP P2) licensing is included with the Enterprise Mobility & Security E5 license, but can be added on to other licensing, such as the EM&S E3 license.

What’s great about it is that it also allows you to use the Microsoft Graph to query your Azure AD tenant and identify potential threats to your organization and even configure an automated response to them. This post will show you how to find these sorts of events in your organization, with a very simple script.

It only takes about 5 minutes to set up, so let’s get started!

What Do I Need to Do This?

For the steps below, I’m using a trial tenant with Office 365 E5 and EM&S E5 licensing (which as mentioned above, includes the Azure AD Premium P2 licensing). This means I don’t have a fully-functioning Azure tenant, where I can set up virtual machines, web apps, containers and so on – but I have enough to do the steps below.

First, I log in to my Office 365 tenant and go to the Admin Centers and click on my Azure Active Directory admin center. I can, of course, just go to http://portal.azure.com and log in there, but this just helps illustrate the connection between the Office 365 tenant and Azure AD.

Click on the Azure Active Directory icon and see all the properties of the Azure Active Directory instance that underpins my Office 365 and EM&S tenant.

I click on App registrations, as shown below:

Click on New application registration

Now I fill in the properties for the new application registration.

The values below will work as shown.

Click Create when finished.

Click on the Settings gear as shown below:

One of the settings is Required permissions .

Click on the arrow to expand this property.

Next, click on Add to set up permissions for connecting to the Graph API.

You have the option of selecting which API you want to grant access to.

Click on the Select an API arrow.

You’ll now see a bunch of API’s that you can connect to.

For our purposes, we’ll choose the Microsoft Graph, which contains security event information.

Click Select at the bottom of that pane.

Now click on Select permissions.

In the Enable access page, scroll down till you see the Read all identity risk event information line.

Click the checkbox next to that line and then click Done.

You should see the Windows Graph in your Required permissions page.

Click on Grant permissions to apply the permissions you just selected.

When you click on Grant permissions, you’ll be asked for confirmation, so click Yes if you agree.

Back in the Settings page of your Application, click on Keys.

Configure an access key as shown below and click Save.

You should see the access key value in the field below.

Copy this key and save it somewhere. You’ll use it in the script as the $ClientSecret variable.

Back on the Properties of the application itself, you will also see the Application ID value.

Copy this value somewhere as well. This will be used in the script as the $ClientID variable.

Use a PowerShell script to connect to Microsoft Graph and Look for Identity Risk Events

The script below can be used to query the Microsoft Graph for identity risk events. You’ll need to fill in the following values:

$ClientID
$ClientSecret
$tenantdomain

For my script, it looked like the screen capture below.

I deleted the application after running the script so these credentials aren’t valid anymore.

Shown below is the sample script for querying the Microsoft Graph to capture identity risk events.

$ClientID       = "Application ID value from the Registered App properties page "       # Should be a ~36 hex character string; insert your info here
$ClientSecret   = "Password value from the Keys page" # Should be a ~44 character string; insert your info here
$tenantdomain   = "Tenant name"   # For example, contoso.onmicrosoft.com

$loginURL       = "https://login.microsoft.com"
$resource       = "https://graph.microsoft.com"
$body      = @{grant_type="client_credentials";resource=$resource;client_id=$ClientID;client_secret=$ClientSecret}
$oauth     = Invoke-RestMethod -Method Post -Uri $loginURL/$tenantdomain/oauth2/token?api-version=1.0 -Body $body
Write-Output $oauth
if ($oauth.access_token -ne $null) {
   $headerParams = @{'Authorization'="$($oauth.token_type) $($oauth.access_token)"}
   $url = "https://graph.microsoft.com/beta/identityRiskEvents"
   Write-Output $url
   $myReport = (Invoke-WebRequest -UseBasicParsing -Headers $headerParams -Uri $url)
   foreach ($event in ($myReport.Content | ConvertFrom-Json).value) {
       Write-Output $event
   }
} else {
   Write-Host "ERROR: No Access Token"
}

Once you fill in the appropriate values for your environment, you can run the script in PowerShell and it will find any identity risk events associated with your tenant.

What Information Does It Provide?

In my tenant, it found one identity risk event, as shown below:

What this tells me is that on February 26, 2018 there was an AnonymousIPRiskEvent that took place using Allan DeYoung’s user account.

It looks like someone logged in with his credentials using a TOR browser, and it was classified as a medium risk event.

Additionally, I am able to see the location where this event took place and the IP address associated with it.

From there, I am able to start tracking down what happened and see if it poses any risk to my network or Allan’s account.

What other types of events would we be able to identify? Microsoft Graph contains identify events such as:

Impossible travel to atypical locations (Did you log in from New York and then 5 minutes later try to log in from an IP address in Indonesia?)
Sign-in events from unfamiliar locations (Is the location you are signing in from outside of your typical login patterns?)
Sign-ins from an infected device (Is the device where the login was attempted communicating with a botnet server?)
Sign-ins from IP addresses with suspicious activity (Maybe an IP address where a number of login attempts are taking place for lots of different accounts, which could indicate a brute force password attack)

We can categorize the risk events because the Microsoft Graph maintains information related to billions of login events each month. That means we can detect anomalies and determine whether they are just a user who forgot their password three times, or some sort of automated attack against that user’s account.

This is a very simple example, but you could configure something like this to run periodically and dump the events to a SIEM, allowing you to collect all your security related events in a single place and have them reviewed by your security team.

There are LOTS of other event types you can query on using the Microsoft Graph API (and the other application-specific API’s). I encourage anyone who manages the security for a network to take advantage of these API’s and create automated scripts that can capture risk events on your network.

Have fun with Microsoft Graph!

Secure Your Office 365 Tenant – By Attacking It (Part 2)

Published on April 4, 2018 by Dave Branscome2 Comments

By David Branscome

In my previous post (https://blogs.technet.microsoft.com/cloudyhappypeople/2018/04/04/secure-your-office-365-tenant-by-attacking-it ), I showed you how to use the Office 365 Attack Simulator to set up the Password Spray and Brute Force Password (Dictionary) Attacks.

What we often find, though, is that spear phishing campaigns are extremely successful in organizations and are often the very first point of entry for the bad guys.

Just for clarity, there are “phishing” campaigns and there are “spear phishing” campaigns.

A phishing campaign is typically an email sent out to a wide number of organizations, with no specific target in mind. They are usually generic in nature and are taking the approach of “spreading a wide net” in hopes of getting one of the recipients to click on a URL or open an attachment in the email. Think of the email campaigns you’ve likely seen where a prince from a foreign country promises you $30 million if you’ll click on this link and give him your bank account information. The sender doesn’t particularly care WHO gets the email, as long as SOMEBODY clicks on the links.

On the other hand, a spear phishing campaign is much more targeted. In a spear phishing campaign, the attacker has a specific organization they are trying to compromise – perhaps even a specific individual. Maybe they want to compromise the CFO’s account so that they can fraudulently authorize money transfers from the organization by sending an email that appears to be coming from the CFO. Or maybe they want to compromise a highly-privileged IT admin’s email account so that the attacker can send an email asking users to browse to a fake password reset page and harvest user passwords. The intent with a spear phishing campaign is to make the email look very legitimate so that the recipients aren’t suspicious – or perhaps they even feel obligated to do as instructed.

What Do I Need?

As you can imagine, setting up a spear-phishing campaign takes a little more finesse than a brute force password attack.

First, decide WHO the sender of the spear phishing email will be. Maybe it’s HR requesting that you log in and update your benefits information. Or perhaps it’s the IT group asking everyone to confirm their credentials on a portal they recently set up.

Next, decide WHO you want to target with the campaign. It may be the entire organization, but keeping a low profile as an attacker also has its advantages.

You’ll probably want to use a realistic HTML email format so that it looks legitimate. The Attack Simulator actually provides two sample templates for you, as we’ll see below. Using the sample templates makes the campaign very easy to set up, but as you get more comfortable using the Attack Simulator, you will likely want to craft your own email to look more like it’s coming from your organization.

That should be enough to get us started.

Launching a Spear Phishing Attack

In the Attack Simulator console, click on “Launch Attack”.

At the Provide a name to the campaign page, choose your own name, or click on “Use template”. If you click on “Use template” you will see two template options to choose from. I’ve chosen “Prize Giveaway” below:

Next, select the users you want to “phish”. You can select individual users or groups.

On the next page, if you’ve selected a template, all the details will be filled in for you. One important value to note here is the Phishing Login server URL. Select one of the phishing login servers from the drop down. This is the way the attack simulator is able to track who has clicked on the URL in the email and provides reporting.

Note that the URL’s for the phishing login servers are NOT actually bad sites. They are sites set up specifically for the purposes of this tool’s functioning.

In the Email body form, you can customize the default email. Make sure that you have a variable ${username} so that the email looks like it was sent directly to the end user.

Click Confirm, and the Attack Simulator will send the email out to the end users you specified.

Next, I opened the Administrator email account that I targeted and saw this:

Notice that it customized the email to the MOD Administrator account in the body of the email.

If I click on the URL (which points to the http://portal.prizesforall.com URL we highlighted earlier) I get sent to a website that looks like this.

Finally, if I click on the reporting area of the Attack Simulator, I can see who has clicked on the link and when.

Okay. But seriously…would you really have clicked on that URL?

Probably not.

So how do you make it a little more sophisticated?

Let’s create a more realistic attack.

In this attack we will use the Payroll Update template, which is very similar to what you might actually see in many corporate environments. You can also create your own HTML email using your organization’s branding and formatting.

I’ll again target the MOD Administrator because he seems like a good target, since he’s the O365 global admin (and seems to be somewhat gullible).

In this situation though, instead of sending from what appears to be an external email address (prizes@prizesforall.com, used in the previous attack) I’m going to pose as someone the user might actually know. It could be the head of HR or Finance or the CEO. I’ll use the actual email address of that person so that it resolves correctly.

Notice that this templates uses a different phishing login server URL from the drop down. You’ll see why in a second.

In the Email body page, we’ve got a much more realistic looking email.

It should be noted, though, that if you make the email look ABSOLUTELY PERFECT and people click on the URL, what have they learned? It’s best to provide a clue in the email that a careful user would notice and recognize as a problem. Maybe send the official HR email from someone who isn’t actually in HR, or leave off a footer in the email that identifies it as an official HR email. Whatever it is, there should be something that you can use to train users to look out for.

So if you read the email template below carefully, you’ll see some grammatical errors and misspellings that should be a “red flag” to a careful user.

Again, you Confirm the settings for the attack and the attack launches.

Going to the MOD Administrator’s mailbox….that’s much more realistic, wouldn’t you say?

When I click on the “Update Your Account Details” link, I get sent to this page, where I’m asked to provide a username and password, which of course, I dutifully provide:

Notice, however, that the URL at the top of the page is the portal.payrolltooling.com website – even thought the page itself looks like a Microsoft login page. Many attacks will mimic a “trusted site” to harvest credentials in this manner. When you’re testing you can use any email address (legitimate or not) and any password for testing – it isn’t actually authenticating anything.

Once I enter some credentials, I am directed to the page below, which lets me know I’ve been “spear phished” and provides some hints about identifying these kind of attacks in the future:

And finally, in the reporting, I see that my administrator was successfully spear phished.

The Value of Attack Simulations

This is all interesting (and a little bit fun) but what does it really teach us? The objective is that once we know what sort of attacks our users are vulnerable to (password or phishing are the two highlighted by this tool), then we can provide training to help enhance our security posture. Many of the ransomware attacks that are blanketing the news lately started as phishing campaigns.

If we can take steps to ensure that our users are better equipped to identify suspicious email, and help them select passwords that aren’t easily compromised, we help improve the organization’s security posture.

Secure Your Office 365 Tenant – By Attacking It (Part 1)

Published on April 4, 2018 by Dave BranscomeLeave a comment

By David Branscome

I’ve been waiting several months for this day to arrive. The Office 365 Attack Simulator is LIVE!

If you log into your Office 365 E5 tenant with the Threat Intelligence licensing, it shows up here in the Security & Compliance portal.

When you click on it, the first thing it will tell you is that there are some things you need to set up before you can run an actual attack. There’s a link that says, “Set up now” (in the yellow box shown below). After you click that link, it says the setup is complete, but you’ll have to wait a little while before running an attack. (I only had to wait about 10 minutes when I set it up)

It also reminds you that you need to have MFA (multi-factor authentication) set up on your tenant in order to run an attack. This makes a lot of sense, since you want to ensure that anyone who runs the attack is a “good guy” on your network.

To set up MFA, follow the steps here:

Go to the Office 365 Admin Center

Go to Users> Active users.

Choose More> Setup Azure multi-factor auth

Find the people who you want to enable for MFA. In this case, I’m only enabling the admin account on my demo tenant.

Select the check box next to the people you want to enable for MFA.

On the right, under quick steps, you’ll see Enable and Manage user settings.

Choose Enable.

In the dialog box that opens, choose enable multi-factor auth.

The Attacks

Spear Phishing

With a spear phishing attack, I’m sending an email to group of “high-value” users – maybe my IT admins, the CEO/CFO, the accounting office, or some other user group whose credentials I want to capture. The email I send contains a URL that will allow me to capture user credentials or some other sensitive data as part of the attack. When I set up this attack, it needs to look like it’s coming from a trusted entity in the organization. Maybe I’ll set it up to make it appear as though it’s coming from the IT Security group asking them to verify their credentials.

Brute Force Password (a.k.a., Dictionary Attack)

In this attack, I’m running an automated attack that just runs through a list of dictionary-type words that could be used as a password. It is going to use lots of well-known variations, such as using “$” for “s” and the number 0 for the letter O. If you thought Pa$$w0rd123 was going to cut it as a secure password on your Office 365 account, this attack will show you the error of your ways.

This type of attack is pretty lengthy in nature because there are thousands of potential guesses being made against each user account. The attack can be set up to vary in frequency (time between password guesses) and number of attempts.

It’s important to note that if a password is actually found to be successful, that password is NOT exposed to anyone – even the admin running the attack. The reporting simply indicates that the attack was successful against Bob@contoso.com, for example.

Password Spray Attack

A password spray attack is a little different from the brute force password attack, in that it allows the admin/attacker to define a password to use in the attack. These would typically be passwords that are meaningful in some way – not simply an attempt using hundreds, or thousands of guesses. The password you use could be something like the name of a football team mascot and the year they won a championship, or the name of a project that people in one department are working on. Whatever criteria you select, you define what password or passwords should be attempted and the frequency of the attempts.

Ready? Let’s go hunting…

Launching a Password Spray Attack

First, I’ll try the password spray attack. I’ve set up several accounts in my test tenant with passwords that are similar to the one I’ll attempt to exploit – which is Eagles2018!. Notice that, by most criteria, that’s a complex password – upper and lower case, alphanumeric and it includes a special character, but it’s also a fairly easily-guessed password, since the Philadelphia Eagles won the Super Bowl in 2018 (though it pains me to say that).

I’ve set up a couple users with that password to ensure I get some results.

I go to my Attack simulator and click on Launch Attack.

The first screen is where I name the attack.

Next, I select the users I want to target. Notice that I can select groups of users as well.

Now I manually enter the passwords I want to use in the attack.

Confirm the settings, click Finish and the attack will begin immediately.

If I go back to my Attack Simulator console, I can see the attack running.

After the attack completes, I see the users who have been compromised using the password.

(Yes, I’ve reset their passwords now, so don’t try and get clever.) 😊

Now I politely encourage ChristieC and IrvinS to change their password to help ensure their account security.

Launching a Brute Force Password (Dictionary Attack)

Again, I’ve set up a couple accounts with some pretty common password combinations (P@ssword123, P@ssw0rd!, etc..)

I walk through the configuration of the attack, which is very similar to the Password Spray attack setup.

I set up my target users as before, and then I choose the attack settings.

In this case, I uploaded a text file containing hundreds of dictionary passwords, but you can create a sampling of several passwords by entering them manually one at a time in the field above the Upload button.

As the attack runs, you’ll see something like the screenshot below. Remember, if you have a large number of users and a very large wordlist for the dictionary attack, this attack will run for quite some time as the simulator cycles through all the possible variations for each user.

And again, when the simulation is complete, you’ll want to caution DiegoS on his lack of good password hygiene.

In my second blog post, I’ll show you how to do a Spear Phishing Attack. These are the REALLY sneaky ones….

Stay tuned!

“Argh…My Skype for Business Recording Failed!!”

Published on March 26, 2018 by Dave Branscome1 Comment

By David Branscome

I recently received a call from a colleague who had been working on a two-hour Skype for Business meeting.

At the end of the call, she went into her Recording Manager to get the recorded meeting but saw that the recording for the meeting had failed. It was showing up as “0 bytes” in size.

When we browsed to C:Users%USERNAME%AppDataLocalMicrosoftCommunicatorRecording ManagerTemporary Recording Files we saw this:

So, we were pretty sure that the files were available, they just hadn’t been finalized at the end of the meeting into a single file. But how do you fix it?

Actually, the fix was pretty easy.

First, start a new Skype for Business meeting. It can be a meeting with just one person.

Once the meeting is started, share out your desktop.

Now start the recording.

Immediately afterward, pause the recording as shown below:

Go to the temporary recording files path:

C:Users%USERNAME%AppDataLocalMicrosoftCommunicatorRecording ManagerTemporary Recording Files and locate the folder with the temporary files for the RECORDING YOU JUST PAUSED. It should be easy to locate based on the time stamp.

Open that folder and delete all the files EXCEPT the file named lock.lock.

Next, go back to the C:UsersdabranAppDataLocalMicrosoftCommunicatorRecording ManagerTemporary Recording Files path and locate the folder for the FAILED recording. Again, you can use the timestamps on the files to ensure you have the right files. Select all the files in this folder and copy them using either CTRL-C or the Copy command

At this point, you should have all the files from the folder of the original FAILED Recording copied over into the folder for the NEW, paused recording.

Now, from your Skype for Business client, STOP the recording for the meeting you initiated earlier. This will start the process of combining all the files from the FAILED recording into a single, functional recording.

Go into your System Tray in the lower right corner and click on the Recording Manager icon and select “Open”

Ensure that the New recording is being compiled, as shown by the green progress bar.

In a few minutes (depending upon the length of the original meeting), your file should be completely recovered and ready to use!

The End of Support for Older TLS Versions in Office 365

Published on December 22, 2017 by Dave Branscome4 Comments

by David Branscome, with a callout to Joe Stocker at Patriot Consulting for the heads-up!

The SSL/POODLE Attack Explained

UPDATE: As per the support article listed here (https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365) We will be extending support for TLS 1.0/1.1 through October 31, 2018 in order to help ensure our customers are adequately prepared for the changes.

As most of you know, there was a significant vulnerability identified in the SSL 3.0 protocol back in 2014, named POODLE (Padded Oracle On Downgraded Legacy Encryption).

The problem was this: SSL 3.0 is basically an obsolete and insecure protocol. As a result, it has been, for the most part, replaced by its successors, TLS 1.0 and TLS 1.2. The way a client-server encryption negotiation sequence would typically work is that the client would contact a server, and through a handshake process, agree on the highest level of security over which they both can communicate. So, for example, a client makes a request to a server and says, “I’d like to use TLS 1.2 for our communication, but I can also use TLS 1.0, if you need to.” The server responds with, “I don’t speak TLS 1.2, but I do speak TLS 1.0, so let’s agree to use that.” They then use that downgraded protocol as their preferred encryption method. The downgrade sequence could ALSO downgrade the encryption to use SSL 3.0, if necessary.

However, even in situations where client and server both support the use of the newer security protocols, an attacker with access to some portion of the client-side communication could disrupt the network and force a downgrade to the SSL 3.0 encryption. This is typically referred to as a man-in-the-middle attack, because the attacker sits on the network between two parties and captures their communication stream. This is an altogether separate type of attack, unrelated to the POODLE vulnerability itself, and must be defended against using other methods.

Anyway, now that the attacker has successfully forced SSL 3.0 encryption to be used, and the attacker has access to the communication stream, the attacker can attempt the POODLE attack and get access to decrypted information between the client and the server.

When this vulnerability came out, there was a significant amount of work done worldwide to mitigate the impact and scope of the issue. The vulnerability in SSL 3.0 itself couldn’t be remediated because the issue was fundamental to the protocol itself. Because of this, the best solution for organizations was simply to disable support for SSL 3.0 in their applications and systems.

So That Was 3 Years Ago….

As described in the links at the bottom of this article, Microsoft still supports the use of TLS 1.0 and 1.1 for clients connecting to the Office 365 service. However, due to the potential for future downgrade attacks similar to the POODLE attack, Microsoft is recommending that dependencies on all security protocols older than TLS 1.2 be removed, wherever possible. This would include TLS 1.1/1.0 and SSL v3 and V2.

The problem here is that many operating systems and applications have a hardcoded protocol version to ensure interoperability or supportability. In Windows 8 and Windows Server 2012 and higher, the default protocol that is used is TLS 1.2 – which is good.

However, in Windows 7 and Windows 2008 R2, TLS 1.0 was the default protocol. In fact, TLS 1.1. and 1.2 were actually configured as “disabled”. See the table below:

As outlined in the article “Preparing for the mandatory use of TLS 1.2 in Office 365”, this is going to present a problem if your organization is still using Windows 7/Vista clients. Why?

Because on October 31, 2018, Microsoft Office 365 will be disabling support for TLS 1.0 and 1.1. This means that, starting on October 31, 2018, all client-server and browser-server combinations must use TLS 1.2 or later protocol versions to be able to connect without issues to Office 365 services. This may require certain client-server and browser-server combinations to be updated.

Our internal telemetry of client connections indicates that this shouldn’t be a problem for most organizations, since the majority are not using TLS 1.0 or 1.1, anyway. However, for the network you manage it’s probably a good idea not to simply assume everything will be great. 😊

As an example, if you’re using any on-premises infrastructure for hybrid scenarios or Active Directory Federation Services, make sure that these infrastructures can support both inbound and outbound connections that use TLS 1.2.

How Do I Know if I Need to Take Action?

A new IIS functionality makes it easier to find clients on Windows Server 2012 R2 and Windows Server 2016 that connect to the service by using weak security protocols.

https://cloudblogs.microsoft.com/microsoftsecure/2017/09/07/new-iis-functionality-to-help-identify-weak-tls-usage/

There are also some simple checks available from Qualys Labs to check browser compatibility – https://www.ssllabs.com/ssltest/viewMyClient.html as well as the certificate and encryption configuration on your servers with SSL certificates – https://www.ssllabs.com/ssltest/ .

Hopefully these checks will help you to ensure that your organization is ready when the change is made to the Office 365 services early next year.

Additional Resources

Preparing for the mandatory use of TLS 1.2 in Office 365

https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365

Solving the TLS 1.0 Problem

https://www.microsoft.com/en-us/download/confirmation.aspx?id=55266

Disabling TLS 1.0/1.1 in Skype for Business Server 2015 – Part 1 and 2

https://blogs.technet.microsoft.com/nexthop/2018/04/18/disabling-tls-1-01-1-in-skype-for-business-server-2015-part-1/

https://blogs.technet.microsoft.com/nexthop/2018/04/18/disabling-tls-1-01-1-in-skype-for-business-server-2015-part-2/

Implementing TLS 1.2 Enforcement with SCOM

https://blogs.technet.microsoft.com/kevinholman/2018/05/06/implementing-tls-1-2-enforcement-with-scom/

Exchange Server TLS Guidance

https://blogs.technet.microsoft.com/exchange/2018/01/26/exchange-server-tls-guidance-part-1-getting-ready-for-tls-1-2/

https://blogs.technet.microsoft.com/exchange/2018/04/02/exchange-server-tls-guidance-part-2-enabling-tls-1-2-and-identifying-clients-not-using-it/

https://blogs.technet.microsoft.com/exchange/2018/05/23/exchange-server-tls-guidance-part-3-turning-off-tls-1-01-1/

Intune TLS Guidance

https://blogs.technet.microsoft.com/intunesupport/2018/06/05/intune-moving-to-tls-1-2-for-encryption/

Preparing for TLS 1.0/1.1 Deprecation – O365 Skype for Business

https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Preparing-for-TLS-1-0-1-1-Deprecation-O365-Skype-for-Business/bc-p/223608

Moving Your Office 365 Groups to Microsoft Teams – Getting Past the Gotchas

Published on November 29, 2017 by Dave Branscome2 Comments

By now, most of us know that Microsoft Teams is built on Office 365 Groups. Additionally, many customers had been using Office 365 Groups for some of their collaboration before Microsoft Teams was released. That means that there are a number of Office 365 Groups out there, that may need to be converted to Microsoft Teams. The general process for using an Office 365 Group as the foundation for a Microsoft Team is well documented, and it would seem to be fairly straightforward. However, as anyone who has actually done this knows, it isn’t quite that simple.

The purpose of this article is to help you move the data that may exist in your Office 365 Group – such as email, OneNote, Planner, etc…over to a newly created Microsoft Team.

We’ll start with a brand-new Office 365 Group, create some content and then convert everything over to a new Team.

Let’s get started…

Creating the Office 365 Group and Populating it with “Stuff”

Let’s start by creating a new Office 365 Group so we know exactly what happens.

Here, I am creating an Office 365 Group named O365-TeamsUpgrade. Notice that it has been created with the default Privacy setting of “Private”.

Next, I add some of my team members to the Group.

Now my Office 365 Group is ready to go, and I have all the usual things in my configuration.

I can send email to the group, because every Office 365 Group has an associated email address. As expected, the email and meeting invites show up in the Office 365 Group mailbox, which exists in Exchange Online.

I go to Files and create a Word document.

Next, I go into my Notebook and create some content in the Office 365 Groups OneNote

I can go into Planner next and create some content there….

Lastly, I click on the Site link and I see the SharePoint Site.

If I go to the Documents library I see the Word document that I created just a few minutes ago.

So, we all agree I have legitimate content in my Office 365 Group, right? Right.

Okay, now comes the fun part –converting it to Microsoft Teams.

Upgrading to a Microsoft Team

In my Microsoft Teams client, I click “Add team”.

Next, I click on Create team.

In the next dialog box, I can create a brand-new Team, or as shown below, I can create one from an existing Office 365 Group. That’s what I want to do, so I click on that link.

It now provides me with a list of the Office 365 Groups for which I am the Owner, and which are set to Private visibility.

I click the radio button and click Create team.

NOTE:

When upgrading an Office 365 Group to a Microsoft Team, there are several points that you must keep in mind:

You must be the Owner of the Office 365 Group

The Office 365 Group visibility must be set to Private. If it is not set to Private, you can set it to Private long enough to do the switch and then turn it back to Public once you’ve switched it over to a Microsoft Team.

There cannot be a Team that already exists with the name of the Office 365 Group you intend to convert. If it exists already, you’ll end up with two disconnected objects. For example, I created a brand-new Team with the same name as my Office 365 Group.

It lets me create the Team with that name, but it doesn’t bring over any of the content from the Office 365 Group with the same name.

Lastly, Teams doesn’t support these characters: ~#%&*{}+/:<>?|'”.. This, if any of your Office 365 Groups are named using those characters, you won’t be able to convert them to a Microsoft Team without renaming them.

Not cool, man…not cool

So far, everything is going just swimmingly, wouldn’t you say? Now I just open up my brand-spanking-new Microsoft Team and I see all the stuff from my old Office 365 Group, which has been converted over, just like magi……..wait….what happened? It only moved over the group membership? Where’s my super important Word document???? Where’s my Planner? Where’s the OneNote?

Let’s investigate…

Files

If we go back to our Office 365 Group (it still exists), we see our Word document still sitting in the Files area. On the far-right side, click on “Browse Library”.

Microsoft Teams stores documents and files in a folder in the SharePoint Document Library which is named for the Channel. By default, the only channel that exists in a new Microsoft Team is named “General”. Therefore, the SharePoint library shows me that my Word document is sitting outside of the General channel, as you see below.

If I select my Word document and click on the ellipsis, I can choose to move the document.

Let’s move it to the General folder. You can move all of your documents to the General folder, or if you have more channels in your Team, you can move them to any channel you like.

I now go to my Team and there’s my Word document in the General folder!

OneNote

But wait, I also had some business-critical information in OneNote. Where did that go?

Well, unfortunately there aren’t any really great options for moving your OneNote from an Office 365 Group over to a OneNote in Teams.

Here’s one way to do it:

In your Teams client, go to the channel of your preference, and click on the “+” sign to add a tab to that channel. In this case, I’m adding a tab to the General channel.

You’ll be presented with a number of options. Select the one that says OneNote.

Create a new OneNote notebook, and name it whatever you like. For my example, I’ll name it O365-TeamsUpgrade01

If I go back now to my Office 365 Group, I see the newly created OneNote notebook, and it exists beneath the notebook that existed already.

Now I can copy the individual pages from one notebook to the other. I right-click on the page and select “Copy”.

I switch over to the new notebook, right-click and select “Paste”.

For my example, I deleted the “Untitled Page” and I’m left with only the page from my original OneNote.

And back in my Microsoft Teams client, everything looks good as well.

Planner

Mercifully, moving your Planner files over is relatively easy.

First you go into the new Microsoft Team and select the “+” sign to add another tab to the appropriate channel. Click on the Planner icon.

In the next dialog window, select “Use an existing plan”, and from the drop-down menu, select the name of the appropriate Office 365 Group.

And just like that, all your Planner information is switched over to Microsoft Teams.

Email

The last thing that needs to be converted over is email.

Again, there unfortunately isn’t a great story there yet. Here’s one idea that you can use.

As we have seen, each Team channel has its own email address. You can get that email address by going to the channel (such as General), clicking the ellipsis and selecting “Get email address”.

Copy the SMTP address, which is the section that’s highlighted below – 62057b2c.microsoft.com@amer.teams.ms (Yours will be different).

Now, go back to your Office 365 Group, select the email you want to move and click on “Forward”. In the new email window, copy the email address for the Teams channel into the “To” field in the email and click “Send”.

Go back to your Teams – General channel and you’ll see the email that has been forwarded from the Office 365 Group email inbox.

This is definitely not the easiest process in the world, and it tends to be error-prone if you have lots of email, but it will get the email conversations moved over.

Now, there may still be some people who will accidentally use the Office 365 Group email address. How do you account for that? One way is to add the new Microsoft Team as a member of the Office 365 Group.

Go in to the membership of the Office365 Group and click “Add members”.

In the dialog window, select the email address of the Microsoft Teams channel where you want the new emails to be delivered.

In my case, I select the email address beginning with “62057b2….” and click “Save”.

Next, go into the Group settings and select “Manage group email”.

In the dialog box, select “Follow in inbox” and click “Save”.

Now, when an email is sent to the address of the Office 365 Group, it is also sent to the email address of the Microsoft Teams channel that I have designated, as you can see below.

Well, that was easy, wasn’t it?

Obviously, I’m being a little sarcastic…this isn’t the easiest process, and there are certainly ways that much of it can be scripted, but for a quick and dirty way to move a few Office 365 Groups over to Microsoft Teams, it should be sufficient for your needs.

Killing Sessions to a Compromised Office 365 Account

Published on October 5, 2017December 31, 2018 by Dave Branscome1 Comment

David Branscome

Partner Technical Architect

We live in a world full of nasty threats to our online environments. One of your end users might click on a link that they shouldn’t and they get sent to a location where a piece of malware is installed on their machine and it captures their user credentials. In many cases, the goal of the attacker is to compromise a user account – ANY user account – and then move forward from there. Maybe their goal is to use that email account to send spam email or access organizational data for exfiltration. Or maybe the bad guy wants to have access to the environment so that he can gather confidential information and misuse it.

If an account in your Office 365 environment is compromised in this way, what can you do?

We have to recognize that there are two basic approaches to the problem:

Watch what the bad guy does so that you can take legal action against them

In this case, the actions we take will be done on the advice of the customer’s legal team and will be designed to establish a legal framework for prosecution. For example, there may be a scenario where an employee has been fired, but he knows the CEO’s password – maybe because the CEO left it on a sticky note on his monitor? Nah. That NEVER happens. The fired employee then decides to access the CEO’s mailbox for some nefarious purpose.

What can we do in this situation? Again, on the advice of the customer’s legal team, you may want to take steps such as the following:

Put the CEO’s mailbox on Litigation Hold so that the data in the mailbox is preserved in its entirety. https://technet.microsoft.com/en-us/library/dn743673(v=exchg.150).aspx
Configure Exchange Transport Rules so that all incoming as well as outgoing email is also forwarded to a second mailbox for preservation. https://technet.microsoft.com/en-us/library/jj919238(v=exchg.150).aspx
If the compromise is severe enough, it may be advisable to set up a new, temporary Office 365 tenant so that communications related to the legal case are handled out-of-band and cannot be seen by the bad actor. This tenant would be where the legal team, IT and the users whose accounts have been compromised can communicate without the risk of their email being read by the bad guy.

Kill the session to block access to all Office 365 resources

The thing to remember about this effort is that we have to do more than simply block access to the mailbox. The user’s identity can be leveraged across multiple Office 365 services, so we have to block access to all those additional services as well. The challenge is that, in order to improve performance, the services often will cache the credentials of the user for a period of time, which means that EVEN IF you change the user’s password, there will be a period of time when the bad actor can remain authenticated and do damage.

That means that we have to break the sessions that allow them to connect to any of the services. There are three ways we can accomplish this:

For the first method, we need to sign in to the Office 365 Admin portal. Then go to Users –> Active Users, and then select the account of the compromised user. Expand OneDrive Settings, go to the Sign-out area, and click on the Initiate link. Notice that this will sign out users from all Office 365 sessions across all devices, but it will still allow the user to sign in. That means the bad actor can immediately sign back in and go about his day. We’ll address password change in a moment.

When you click Initiate, the service begins killing the sessions for the user on all their devices.

At this point, it’s a good idea to also block further sign-ins for the user. Granted, it’s impactful, but so is having a compromised account.

To block sign in, from the properties of the compromised user account, go up to Sign-in status and edit the status.

Change the status of the account to “Sign In Blocked”

With the sign-in blocked, nobody (good or bad) can re-authenticate using that account until an administrator unblocks the account. When you click Save, notice the recommendation given.

This reminds us that another good idea is to change the user’s password.

The second method is specific to SharePoint and uses the SharePoint Online PowerShell Module, which can be downloaded here: https://www.microsoft.com/en-us/download/details.aspx?id=35588 . Once you have it installed and have connected to your tenant (Steps are here https://technet.microsoft.com/en-us/library/fp161372.aspx) run the Revoke-SPOUserSession cmdlet, as shown below.

The third method actually goes beyond just the Office 365 services and kills all active user sessions in any Azure AD application. To use this method, download the Azure AD PowerShell Module here (https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0).

Once installed, connect to your Azure AD tenant and kill all sessions by using the Revoke-AzureADUserAllRefreshToken cmdlet, as shown below.

Changing the Password

All of this is great, but as we mentioned earlier, if we don’t change the user password, then all we’ve done is make the bad guy sign in again. This is where it can get kind of tricky, especially in a scenario where we have directory synchronization taking place between an on-premises environment and Azure AD.

Remember, it doesn’t do any good to just configure the user properties to have the user change their password at the next logon. The bad guy can try to login, get the prompt to change the password, and change it to whatever he or she wants to use!

If the password is being synchronized to Azure AD, you’ll need to use the Get-MSOLUser cmdlet to identify the LastDirSyncTime and LastPasswordChangeTimestamp value to ensure that the password change has also been synchronized to Azure AD. Make sure that, if the user changed their password in the on-premises directory, the password synchronization has taken place.

What Else Can I Do?

If none of these seem to have blocked access to the mailbox of the compromised user by the bad actor, one more thing you can do is perform a mailbox move. This would effectively break any current sessions the bad actor had open. If the password was changed and synchronized correctly, then the bad actor should not be able to log in again with the old credentials.

To move a mailbox in Office 365, use PowerShell to connect to Exchange Online using these steps: https://technet.microsoft.com/en-us/library/jj984289(v=exchg.160).aspx

Once you are connected, just run New-MoveRequest compromisedUser@contoso.com -PrimaryOnly.

Depending on the size of the mailbox, this could be fairly quick, but for very large mailboxes, it could take a couple hours to move.

One more thing! Don’t forget about mailbox delegates. If a bad actor granted Full Mailbox delegate access to another user, and the delegate user account was also compromised, then the bad actor would retain access to the original mailbox anyway! Therefore, make sure you check the mailboxes and accounts of any delegates of the compromised user so that you are removing all unwanted access to the original mailbox.

Conclusion

There aren’t many things as unnerving and disheartening to an IT admin as finding compromised accounts in your environment. When you find them, don’t panic!

Following a logical set of steps can help you clean up your environment and get things back to their natural order, where you sit back and collect accolades for a job well done, all day long!