At our last Windows
Management User Group Netherlands meeting, we had the honor to have Sami Laiho, one of the world’s leading
professionals in the Windows OS and Security flying over to the Netherlands and
present for our user group. In his presentation titled: “Securing Windows
in 2020 and forward”, Sami made us aware that by implementing some simple
Applocker policies on our Modern Workplace and by making sure that the user
working on the device has no
admin rights, we can seriously improve our security. In his presentation
Sami referred to a quote from Mikko Hyppönen (Chief Research Officer at
F-Secure): “Make your security better than your
blogpost I will share my experience with implementing Applocker policy within
my own tenant, and how I started to use these principles myself which
eventually led by removing my account from the local administrator group.
Disclaimer: This blogpost provides a very
simplistic way of enabling Applocker policies, in the real world there are some
caveats which must be addressed when implementing Applocker. I will
address those caveats later in this post
as a modern workplace consultant also means that sometimes you have to go deep
into Exchange Online options in order to make sure that (sensitive) data of
your customer doesn’t leave the organization without the proper security
measurements taken. In the Microsoft documentation titled: “Best
practices for configuring EOP and Office 365 ATP“, the recommended
settings for both Standard and Strict states that Auto-forwarding to external
domains should be disallowed or monitored at least.
email forwarding is one of the possible and still most common way (sensitive)
company data might leave the organization. Giving the users the ability to
automatically forward emails using either mailbox forwarding or message rules
to users outside the organization in that case can be very risky. I’ve seen
many cases where corporate email accounts were configured to automatically
forward all email to personal gmail.com or hotmail.com accounts. Also still
enabled mailboxes which forward mail to users personal accounts while the user
doesn’t work at the company anymore is common practice.
commonly known that if a user somehow gets compromised, hackers usually put a
forward on the mailbox of the user in order to gain knowledge about the user in
order further continue with their attack methods, or to retrieve sensitive
company data for their own gains.
default, on Windows 10 devices which are Azure AD joined, the user performing
the join is added to the Local Administrator group. Besides the user and the
local administrator (which is disabled by default), two other SIDs are added
without any friendly name which explain who they are. So where are those SIDs
possible to make the user a normal user while enrolling the device, but then
you have to create a Deployment Profile and use Windows Autopilot. See: Configure
Autopilot profiles or use Bulk enrollment. See: Bulk
enrollment for Windows devices
Note: This post reflects the status of Azure AD
local administrative privileges as of February 11th 2020. Functionality may
change, even right after this post has been published.
may know, it’s possible for your users to sign-in to SaaS based applications
using their Azure AD account. By doing this, a Single Sign On (SSO) experience
is created for the user. Before this SSO for an SaaS based application is
possible though, the user needs to accept (a) permission request(s) from the
application allowing the application to access the users data on its users
behalf, even when the user is not using the application.
Added February 11th: Erik Loef pointed me to the following two interesting articles detailing on how oAuth can be used to exploit Office 365 environments. See:
Shining a Light on OAuth Abuse with PwnAuth
Introducing the Office 365 Attack Toolkit
Added May 20, 2020: Microsoft made some new functionality available, please also read my article: “Some welcome additions to the Admin consent workflow in Azure AD” afterwards for the changes Microsoft made.
TL;DR; – Disable user app consent, and enable admin consent requests as soon as possible!
Note: This post reflects the status of Admin
consent as of February 9th 2020. Functionality may change, even right after
this post has been published.