This week has been pretty standard, the usual day to day working on projects and helping those who are under duress. With that said I thought it would be cool to grab three things I worked on and give an overview. This week list is;

• Reactive Incident Consultation
• PowerShell scripts making API calls to a SaaS service to pull Audit data
• Reviewing and defining policies for an identity service, based on the Attack path seen at MGM

Reaction

Part of what I do is focused on reacting to changes that may have happened in an organisation. This week I found myself providing guidance with the rebuild of servers. Normally you would consider this to be part of the eradication and recovery stages of a Cyber Incident. However there are so many things that can go wrong when this stage is executed. Ok lets look at an example; Lets say the system that is being built had been ransomed. The strategy for a lot of organisations is to restore from snapshot/backup. But what if there is an implant in your backup? What about the hash of the local passwords on that system? What about the potential vulnerability that you have just reintroduced!

With those things in mind building a clean system, a trusted source is critical. This in itself opens up additional though on versions of software you are running from OS to Application, however lets not forget any layers of abstraction (Like Virtualised platforms; VM or IaaS) and one of the most easy to neglect, network segmentation.

API calls, PowerShell Scripting

Something I have been painful bad at for sometime was scripting. I mean I could “Hello World” and build a calculator, but I never really had an objective or project that would keep me interested enough to stick it out. Recently however I have had several! And I am thankful for this new challenge. So this week I created a script that would pull audit data from a SaaS Tool, drop the files into a folder it created (if it didn’t exist), then create a bunch of files with the response received. The response I converted to JSON so I could easily identify what information was necessary from the call.

With all this said and done, I then noticed there were somethings that needed to be enhanced. For instance;

• The script had hardcoded credentials.
  • This needs to be fixed, ideally using their PAM tool to provide the credential at time of request
• A service account
  • The script running will need it’s own account on the SaaS platform. This presents a new challenge as the IDP may have conditional access rules in play that need to be modified to meet a service account requirement. Even though the account is read only, this still could offer an opportunity for Recon.
  • The Script needs to be scheduled to run also. This account must not be privileged as why would it be?!
• Depending on region, the SaaS tool had different URI’s.
  • Check responses for clues when documentation lets you down.
• The Tools documentation lacked some critical information about where to make subsequent calls after the initial.
• Typo’s Suck… especially when they are your own 😀

I have been asked, “Why PowerShell, and not Python or another language?”, well I want to LOL (Live of the Land) as much as possible. I prefer to have a script that will run natively on the customers system. In this case, they are a Microsoft house, so yeah, PowerShell!

I also found some assistance by using Postman and it’s clever little feature that gives me code based on the call I want make.

Policies and Federation

In this particular Consult, I worked on setting the roles and permissions necessary to stop an attacker from adding a directory to the identity service. Looking at the attack that happened with MGM and how the attackers were able to use federation as a method to gain access, it is imperative that only the highest level of privilege is able to make changes to the identity structure within and identity tool.

This blends two concepts, Identity Access, and Privileged Account Management.

In this case we created a role that had the correct level of permissions to read configuration, but does not have permissions to modify. We also had to take into account role management. If a user had this permission, they would have shadow administrative access to the federation permissions.

Once this was set, an new method for high privileged access to the IdP was created along with a secure method for providing MFA.

For me this simply echoes the my current feelings on how well organisations truly understand their identity implementations. I think about Active Directory, or Entra, how these services are implemented with convenience in mind. This is great for the end user, but the easier it is for them, the easier it is for an attacker. I’m not saying all simple solutions do not offer protection, infact, kind of the opposite. Physical tokens for MFA are a great way to limit the scope of attack on end users. It helps avoid technical attacks to a mobile device for example (e.g. SIM Swap or Malware). You could look at conditional access for the token when on Mobile, but this certainly has it’s draws backs on the speed you can implement this, depending on the conditions of the eco system (I’m looking at you BYOD).

Wrap up

That is it. The objective of this post is really to put down a few thoughts and air some experiences. Enjoy your week!