I’ve moved sec-test

show a man moving a lot of files that are contaminated and need special care to move them

It was bound to happen sooner or later, my security testing PowerShell script called sec-test.ps1 is being detected as malware on local machines.

Thus, I have relocated it from more common Office365 repo into the less common examples repo here;

https://github.com/directorcia/examples/blob/main/sec-test.ps1

which contains a range of security testing files that typically get detected as malicious and is generally not recommended to sync locally.

Thus, you can sync the Office365 repo down to your desktop to do all the Microsoft 365 PowerShell connecting and use the utilities there without something in there being detected as malware.

Defender for Office 365 Anti-phishing policies can protect externals as well!

My experience with most Microsoft 365 environments I see is that they fail to make use of all the features that are provided. None more so when it comes to security. For example, most people don’t seem to appreciate that the Defender for Office 365 (which is part of Business Premium) provides impersonation protection for internal AND external email addresses! It just needs to be configured. The details are here:

Impersonation settings in anti-phishing policies in Microsoft Defender for Office 365

and as it says there:

You can use protected users to add internal and external sender email addresses to protect from impersonation.

but it is important to note:

User impersonation protection does not work if the sender and recipient have previously communicated via email. If the sender and recipient have never communicated via email, the message can be identified as an impersonation attempt.

This means, you want to get the configuration of important external email addresses in place as soon as possible so any impersonation against those users can be evaluated. It is too late to do after an internal user is communicating with a scam (impersonated) domain.

You will also see that you can also configure protection for external domains, rather than just specific email addresses, for impersonation evaluation.This means that if the users inside the tenant deal with an important business that has its own email email, that is NOT part of that tenant, you can enter that domain in here. Makes a lot sense when you are working with a business regularly that is doing stuff like invoicing, e-commerce or the like (honestly anything at all really).

Let’s say that I work with a business who’s domain is ciaops.com. By enabling this impersonation protection early, if users in the tenant receive email from c1aops.com then it is far more likely to be detected because the system is looking of for spoofing of that custom external domain I entered in the policy.

Thus, if you have Microsoft Defender for Office 365 in your environment (and you do if you have Microsoft 365 Business Premium), then you can provide an extra level of protection by configuring the Anti-Phishing policy for impersonation settings for both your important internal AND external usera and domains (i.e. people and businesses you work with regularly). You should do that as early as possible to provide the maximum protection the policy can provide. They key is that someone has to add in the unique email addresses or domains into the policy, they are not added automatically, even internal email address. They ALL have to be added to the policy.

You can protect up to 350 unique email addresses and 50 unique domains, which is probably more that enough to cover everything a smaller business would need for internal and external users. Unfortunately, I rarely see this great capability enabled. It’s available if you have Microsoft Defender for Office 365 so go configure it and reduce the risk to the users in the tenant. Easy!

CIAOPS Summer School is open for enrolments

In early 2024 I’ll be running a course entitled “Secure more with Secure Score in Microsoft 365”. Training will held virtually over four consecutive weeks. Each session will be two (2) hours and run from 9am Sydney time.The dates are:

Thursday January 4th 2024

Thursday January 11th 2024

Thursday January 18th 2024

Thursday January 25th 2024

The sessions will be recorded and other materials from the sessions (checklists, etc) will be available to attendees afterwards.

This event will be conducted remotely via Microsoft Teams.

The aim of this training is to help configure security best practices inside your Microsoft 365 environment. You’ll learn what settings you should enable and why you should have these enabled. The sessions will also take you through common examples of configuring these settings and the impact they will have on your users.

The price for this event will be:

Gold Enterprise Patron = $48.67

Gold Patron = $97.34 inc GST

Silver Patron = $194.68 inc GST

Bronze Patron = $389.35 inc GST

Non Patron = $599 inc GST

You can learn more about the CIAOPS Patron community at www.ciaopspatron.com.

I hope that you’ll join me in January for this event as I believe it provides some much needed training in a very important aspect of managing and securing Microsoft 365. If you are serious about security for Microsoft 365, then you need a plan and this training will aim to give you just that plus some experience to boot!

You can enrol now in this course ready for January using this link:

https://www.ciaopsacademy.com/p/secure-more-with-secure-score-in-microsoft-3651

As always, if you have any questions about this training please email me on – director@ciaops.com.

I hope to see you there.

Adding a secret to an Azure Key Vault

An Azure Key Vault is a great location for storing credential securely. In a recent article I cover how to:

Create a new Azure Key Vault

next, I want to cover how you can actually put credentials in there.

Step one is to navigate the Azure Key Vault you have created, and select the Secrets option from the menu on the left as shown above. From the menu on the right select +Generate/Import as shown.

Simply complete the fields as shown and select the Create button at the bottom of the window.

You will note that your secret (say a password) has a Name and potentially an activation and expiration date if desired. You can also enable or disable if desired.

You should now see that the secret has been created as shown above. To view the details simply click on the secret.

Here you’ll now see all the details about the secret. The good thing about information about an Azure Key Vault credential is that you can easily update it if required and previous versions will be retained. You can also control access to this individual secret via the Access control (IAM) on the menu on the left hand side.

If you now select the Current version displayed in the middle of the page you will get more details like so:

Here, you can update the settings for secret as well as reveal what the secret is by selecting the Show Secret Value button as shown.

You see the super secret password shown above.

One of the main reasons reasons for using an Azure Key Vault is that we can access this information also programmatically, for example by using PowerShell.

If I connect to Azure using the Azure PowerShell module with a user that has rights to access the vault and secret, I can run a command like:

get-azkeyvaultsecret -vaultname “vaultname” -name “secretname”

and the results will be shown above. But how do I get to the actual secret?

Basically, you repeat the previous command but this time assign it to a variable and add the –asplaintext option, like shown above. The command would look like:

$pwd = get-azkeyvaultsecret -vaultname “vaultname” -name “secretname” –asplaintext

Now the secret value (say password) is in the variable $pwd for use in my code.

PowerShell is not the only method you can use to obtain what is in an Azure Key Vault. You can use something like Power Automate and Flow, which I’ll cover off in an upcoming articles. However, PowerShell allows just about any function with vaults including creating, reading, deleting, updating and so on. Thus, using an Azure Key Vault provides a secure yet flexible method of storing credentials you want to protect as well as make potentially portable (i.e. you can use them anywhere on any device that runs PowerShell and connect to the internet).

So an Azure Key Vault provides secure storage for credentials that you can easily access programmatically using something like PowerShell and Power Automate. What can now be achieved with this? Stay tuned to find out more.

Create a new Azure Key Vault

Given that a number of upcoming articles will discuss Azure Key Vaults, I thought a good place to start was to show you how to set one up. It is pretty easy, so let’s do it!

You’ll need a paid Azure subscription and administrator access to your Azure portal.

In the Azure portal, search for Key Vaults as shown and select Key Vaults from the results.

Then select the option to Create a new vault as shown above.

Complete the details for the vault, including:

– Azure subscription

– Resource group

– Key vault name

– Region

– Pricing tier

most of the other options can be left at their defaults. Select the Next button at the bottom of the window to continue.

In this case the default Permissions model of Azure role-based access control is desired setting.

Generally, no further changes are required. Select Next at the bottom of the windows to continue.

Typically, no changes need to be made here as we will want this new vault to be available publicly via something like PowerShell. However, you can make whatever changes you desire and select the Next button at the bottom of the screen to continue.

Add tags if you wish and then select the Next button at the bottom of the window.

Review the settings you have made and select the Create button.

You should now see the new vault being provisioned as shown above.

When the provisioning you can select the option to view the result as shown above.

You can return to your new vault at any time by navigating to Key Vaults in the Azure portal where you should see the vault just created as shown above.

I’d also suggest you check some permissions before you leave. Open the newly created vault and select Secrets from the menu on the left. If you see the banner across the top as shown above the reads This operation is not allowed by RBAC then you’ll probably need to change some permissions.

Navigate to the Access Control (IAM) option from the menu on the left as shown above. Then on the right select +Add.

From the menu that appears select the Add role assignment as shown above.

Locate and select the Key Vault Administrator job function role as shown.

Select Next at the bottom of the screen to continue.

Click the +Select members hyperlink as shown above.

From the window that appears on the right, search for the user whom you want to have rights over the vault (typically the same user that is currently logged in). Press the Select button at the bottom of the window to continue.

The selected user(s) should now appear under the Members section as shown above.

Press the Next button to continue.

Select the Review + assign button at the bottom of the screen to complete the process.

If you now return to the Secrets area that displayed the original RBAC warning, after a minute or two, you should see that message is longer displayed. The user that you just added now has administrative rights to the vault.

If you want to learn more about what Azure Key Vaults are all about take a look at:

Azure Key Vault basic concepts

however, in essence they are going to place to store stuff you want kept secure, like configurations details, including passwords and then access them programmatically.

Monitoring a break glass account with Sentinel

In a previous article I covered off how to use Defender for Cloud Apps to monitor a break glass account. Typically, the alerts generated there will feed into Sentinel, however it is possible to configure Sentinel to perform a similar role.

The starting point is to use a KQL query like this:

SigninLogs
| where UserPrincipalName == “breakglass@domain.com”
| where OperationName == “Sign-in activity”
| project TimeGenerated, UserPrincipalName, ClientAppUsed, LocationDetails

If you run that query manually you’ll see a result like shown above. You will however also notice a New alert rule option in the top right of the window.

Selecting this will reveal two choices as shown above. Select Create Microsoft Sentinel alert to continue.

Make the appropriate settings in the General page, like shown above, and continue.

Here there are number of settings you can select but you will probably want to adjust how often the query is run as shown above. The important point to remember is that, as Azure is a consumption based billing model, there is a (very, very small charge) every time the query is run. Thus, the more often it runs the more it will cost.

When you have completed this section, move onto the Incident settings.

Here it is important to ensure that the option to Create incidents is Enabled as shown above.

Make any additional adjustments and move to Automated response.

Here you can enable any automation action you wish by selecting from those already created, as shown above. You can always add additional automation later if desired.

Finally, review and create the alert.

Verify that the alert you just created now appears in the list of Analytic rules for your environment as shown above.

If you now test this by logging as your breakglass account you should an incident generated as shown above. Once again, it is important to remember that this incident doesn’t appear immediately. It will appear in a time period based on how often you set the alert to check.

Another important thing to remember is that by default, the incident will not send an email notification of the alert. You can configure that a variety of different ways if you wish, which I won’t cover here.

The differences with using Sentinel for custom alerts is that the billing is consumption based, but you have a lot more flexibility in how you configure the actual alerts as well as any automated response if desired. I would also say that Sentinel has more power around actually analysing signals as well which is handy to protect your breakglass account.

Monitoring a break glass account with Defender for Cloud Apps

It is a very good thing to have a breakglass account in your environment. I have spoken about this in depth in an episode of my podcast:

Need to Know podcast – Episode 310

The challenge can be ensuring you know if and when this account is used because it typically has less protection associated with it than normal accounts in the environment.

One way to achieve this is to use Defender for Cloud Apps, which can be found by navigating to:

https://security.microsoft.com

to generate alerts when the account logs into the environment.

On the left hand menu of the Microsoft Security Center for your tenant expand the Policies option under the Cloud apps heading, and select the Policy management item.

Now select the +Create policy menu item on the right as shown above.

From the drop down that appears, select Activity policy as shown above.

Give the new policy a Name and Description. Select the Policy severity and the Category.

Select the option to Act on: Single activity.

In the Activities matching all of the following select:

Activity Type equals Log on

then add another filter and select:

User Name equals breakglassaccount@domain.com as Any role

as shown above. This in essence will trigger and alert whenever the breakglass account logs into the environment.

Configure the Alerts and Governance actions to suit your requirements. At a minimum you probably want the alert to be emailed to an external address. You can also build a Power Automate Flow from this also if you wish.

Save the new policy.

Locate the policy just created in the list (you can sort using the Modified column if necessary). Select the ellipse (three dots) to the right of the policy entry and from the menu that appears, select View all matches as shown above.

Ensure you test the policy by logging into your breakglass account.

This will now show all the matches in your environment as shown above. It is also recommended that you Save as so you can easily return these results if needed in the Activity log.

If you have also set up Sentinel, the alert should also flow into here as shown above. More automation and alert options are available here if needed.

The most important thing to remember that any alert generated by the login of your breakglass will NOT be immediate! It should however appear with a a few minutes of the action taking place and then a little while after in Sentinel as it flows through the logging process.

There is more that can be done to with this process, but this should get you started protecting your breakglass account.

Block applications on Windows devices using Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

7. Setting an individual Attack Surface Reduction (ASR) rule in Intune

8. Setting Edge as the default browser using Intune

Now that we have Microsoft Edge all set up and have done as much as we can to encourage people to shift away from using other browsers, it’s now time block any other browsing options. We can again use Intune to achieve this and, typically, it can be done using a number of different methods. Here, we’ll use what I consider the easiest method.

Once again, create a Configuration profile for Windows 10 and later using the Settings catalog as shown above.

Give the policy a suitable name and continue.

In the search field type ‘specified windows application’ and select Search. The only category that appears should be Administrative Templates\System, which you should select. Then in the lower pane select Don’t run specified Windows applications (User) as shown above.

Enable the Don’t run specified Windows applications (User) and then enter the name of the applications you do not wish to run. Here, we’ll block chrome.exe and brave.exe as shown above.

These settings are covered in the RestrictApps documentation in which you will note:

1. The setting applies to users not devices:

and

2. This policy setting only prevents users from running programs that are started by the File Explorer process. It doesn’t prevent users from running programs such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting doesn’t prevent them from starting programs in the command window even though they would be prevented from doing so using File Explorer.

3. Blocking occurs by filename only. If users can rename the file then it will execute.

As mentioned previously, this is but the simplest method to block existing applications from running. Other options are available if you wish a more comprehensive blocking approach.

Finish configuring the policy remembering to assign it to a user NOT device group.

Once the policy has been deployed to your fleet and these machines have been rebooted, when a user tried to run an application that you have specified as block in the policy they will receive message like that shown above.

The good thing about this policy is that you can easily extend it to include any other applications you don’t users to run on their Windows devices.