was successfully added to your cart.

MS Teams & SharePoint Online: Some Disintegrations! Part 3

In Part 1 and Part 2 we covered frustration due to poor design and application [dis]integration. Now let’s get to the real juicy part: Exploitability!

But first, some disclaimers.

Disclaimer #1: Remember, this blog is written for educational purposes only. Do not attempt what you are about to read at work, school, or on the Moon because it will probably get you totally fired, arrested, and/or ejected out the nearest airlock!

Talk to your doctor today about whether Levity is right for you.

Disclaimer #2: There are a lot of so-called bad words in the English language. Some are rude, some are obscene, some are just disgusting, some are even “Resume Generating Events”*. For obvious reasons, I am not going to use any of these words in the examples below. Hence, for the sake of demonstration, all potentially offensive terms will be replaced with “sandwich”. I mean, I am just as much into free speech as the next guy but I’m not a total sandwiching moron.

* These ones are so bad that I can’t even tell you want letter they start with

I am going to list several possible scenarios where a user could (purposefully or otherwise) invoke the power of an Microsoft Teams site and cause problems for themselves and others (including you!). Though presented with a measure of levity, these are not just goofy situations that are unlikely to happen. Take heed!


The Lumbergh Effect


Peter, the Bored Genius


Creates a site entitled “Lumbergh is a Sandwich”


Bored. Might be a genius. But probably just bored. Also, really hates Lumbergh.



Just a slightly increased chance of some doofus getting himself in trouble.


Probably never would unless you manually ran


(or Lumbergh found out)


Meh. It’s unprofessional and might get the “Genius” in hot water, but it’s not exactly hate speech. I wouldn’t sweat it too much. But if you want to teach old Pete a lesson, just follow the steps in Part 2 under the heading Reclaiming a Teams URL: Kill it With Fire


Short of disabling the creation of Microsoft Teams site tenant-wide, there is no way to prevent a user from making a sandwich of himself in this fashion. I hear Precognitive Group Policy is in the works….but did it?


Peter may have to just go ahead and come in this Saturday, mmmkay? That’d be great.


The Petulant Teen


Angston, age 15. Lots of adolescent angst.


Creates a site entitled “I am going to KILL Güdteache!”

Did You Notice?

  • The exclamation point and umlaut are dropped
  • The CASE of the Team site title is maintained
  • A teenager actually took the time to properly use an umlaut?!


Sick of Mr. Güdteache giving him sandwiching homework every sandwiching day.



But there could be other serious consequences for young Mr. Angston (see Other Concerns section)


Since terms containing a string like ‘am going to KILL’ would probably never be legit, you could use a simple PowerShell script to scan all your sites for any containing defined triggers.

[code language=”powershell”]
$triggerWords = ‘murder’,’death’,’kill’
foreach($word in $triggerWords)
$site = ((Get-SPOSite -Limit All | Where {$_.Url -like "*$word*"}).Url
if($site.Count -ge 1)
Write-Host "Found site: $site"

Will return:
Found site: https://[tenant].sharepoint.com/sites/IamgoingtoKILLGdteache


Can’t really “fix” teenagers in any lasting way. They will grow out of it in seven years, tops. Just follow (most**) the steps in Part 2 under the heading Reclaiming a Teams URL: Kill it With Fire

** If you are concerned that the site may be called as evidence, remember to NOT run the Remove-DeletedSPOSite step. By skipping that step you will leave the site in a recoverable state for 30 days. If you are really concerned, just leave it alone and talk to the principal. Narc.


Short of disabling the creation of Microsoft Teams site tenant-wide, there is no way to prevent this. Best course (IMO) is to regularly monitor for certain “never okay” trigger words as explained above.


I think it goes without saying that anyone making a direct statement such as this is a very big deal and should be treated as such. Granted, teenagers named Angston can sometimes say ignorant things just to get a reaction. But still, saying something like that is so totally not cool Angston.


The Spear Phisher


Unnamed SharePoint User.


Creates a site entitled “New Hire Onboarding”


A Spear Phisher wants to harvest personal information from unsuspecting users. This will likely be used directly for ID theft or credit card fraud. It can also be packaged with the information from other victims and sold on the black market via the Dark Web, etc.

Note that “Spear Phishing” is distinct from a regular email phishing scam. A regular phishing attempt relies mass mailing and/or inattentive users. This is in contrast to the tactics of a spear phisher, who tries to lure a very specific subset of people of whom they already know some personal facts. They then use emails that are sent at a time and in a method the user would expect. In short, the time-tested advice of “never click on a link in an email unless you were expecting it” goes out the windows because….they were expecting an email.



In this scenario the attacker knows (and will exploit) the following information because they have access to the corporate environment:

  • Any recent additions to the GAL (address book) will probably be from newly created email addresses
  • User logins and email addresses are usually the same
  • Any email sent to these addresses will likely be received by someone who is indeed a newly hired employee

What makes this so easily exploitable?

  • Everything from the sending email to the link destination is 100% legit
  • The spear phishing site URL looks right (it does say ‘NewHireOnboarding’ after all)
  • Asking a new hire for personal information for direct deposit, etc. would not arouse suspicion


Like any ongoing cybersecurity threat, you should always be on the lookout for anything fishy. The SharePoint admin portal’s inability to display MS Teams sites along with everything else makes this particular threat particularly difficult to detect without taking some particularly proactive steps. Even if you do not current suspect anything, I would run the Get-SPOSite command now and again and review the URLs. Better safe than sorry!


Something of this nature is a very serious problem and needs to be addressed immediately. If you get an alert from Office 365, a report from a concerned user, or just happen upon something yourself, here is a way to stop the bleeding.

  1. Run the Get-SPOSite command to see if the site still exists, including in the tenant recycle bin
    • Check currently active sites:
      [code language=”powershell”]
      $fishySiteActive = Get-SPOSite -Limit All | Where {$_.Url -eq [url of suspect site]}
      $active = $fishySiteActive.Count
    • Check the sites in the recycle bin:
      [code language=”powershell”]
      $fishySiteDeleted = Get-SPODeletedSite -Limit All | Where {$_.Url -eq [url of suspect site]}
      $inactive = $fishySiteDeleted.Count
  2. If either the $active or $inactive variables returns a number higher than zero, gather every bit of information you can about these sites via PowerShell and store the output in a secure location.
    [code language=”powershell”]
    $fishySiteActive | Select -Property * | Out-File ‘C:\Some\Secure\Location\ActiveSuspectSites.txt’
    $fishySiteDeleted | Select -Property * | Out-File ‘C:\Some\Secure\Location\InactiveSuspectSites.txt’
  3. Use the process detailed in Part 2 to drill down all the people currently listed as Owners on each site.
  4. From here on, there are pretty much only two choices
    1. Leave the Site(s) alone
    2. Delete the Site(s)
  5. Since there are possible liability issues with either choice, you should consult with your cybersecurity folks about what steps to take next.
  6. If you are the sole member of the cybersecurity team then I guess just talk to yourself until you decide what to do!


The Office 365 Security & Compliance portal now offers alerts that can send email based upon certain trigger events. One of these events is the creation of a new Microsoft Teams site.

Once logged into the portal, go to Alerts. If this is the first time you have used this feature, there will be a message telling you that user and admin activity recording must be enabled first.

Click it. I dare ya.

It will take a minute or so for the activation process to complete. Once it does, click ‘New Alert Policy’ and give your new alert a name and, if you want, a description too.

Leave Alert Type set to ‘Custom’ and expand ‘Send this alert when…’

Using a descriptive name it enhance synergy.

You will notice there are many, many factors you can alert on. Instead of scrolling forever, just use handy search box and look for ‘Team’. You should every alert-able event related to Microsoft Teams sites. Select ‘Created Team’.

Then all you have to do is define which users you want to watch (the default is everyone, including yourself) and to whom you want to alerts to go. This can me any user or distribution list available to Office 365 — outside email address recipients are not currently allowed (if you add one to the list, it won’t be there the next time you enter the form).




There are some things to remember when using the Office 365 Alerts to watch for newly created Teams sites

  1. After the activity recording feature is enabled, it may take 24+ hours before you start getting alerts
  2. After the activity recording feature is enabled, it can only be disabled using this PowerShell command:
    [code language=”powershell”]Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $false[/code]
  3. There is a delay after an alert is triggered before the email is actually sent; don’t expect as-it-happens alerts
  4. If you expecting large numbers of new Teams sites to be created (e.g. start of a new school year), it might be better to leave auditing OFF for a while just to avoid getting a gajillion “alerts”

The folks over at Petri put together a great article focusing entirely on the Office 365 audit. The article is from December 2016, but still worth your time: https://www.petri.com/office-365-audit-data

So here we are at the end of Part 3. What a long strange trip its been, yeah? The good part is, now you know all I know about the hit-or-miss integration between SharePoint Online and Microsoft Teams site. As I said way back in Part 1, I really do like the Teams feature of Office 365. But having the one little ‘/sites/’ part of their URL in common with the rest of SharePoint Online….well, I could write a book. Hey wait! I just did. 🙂

From the Great Pit of Carkoon,


Subscribe to our mailing list

* indicates required