Code Name: The Log Cleaner

Last Updated on September 20, 2022 by rudyooms

This blog will show you how to deal with some Sensitive Information that could end up in the Intune Management Agent Executor Log files.

Some time ago, I wrote the blog about how you could implement LAPS with Intune by using Proactive Remediations.

While writing that blog, I also needed to show everyone how you could deal with sensitive information in those logs, but now I decided it needed a blog on its own.

I will divide this blog into multiple parts.

  1. What information is stored
  2. Fixing the Agent Executor log
  3. Fixing the Registry Reports

1. What is stored inside these logs?

As mentioned in the introduction, there could be some sensitive information stored inside those logs. Those log files are just like the old GPO’s which could also store sensitive information and are readable by everyone/ Authenticated Users.

As a “Very Old” Active Directory example (I know, I know this blog is about Intune… but I need to make my point first!)

Afbeelding met tekst

Automatisch gegenereerde beschrijving

MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege: May 13, 2014 (microsoft.com)

Luckily the “connect as” issue from the picture above was fixed a long time ago, but there could still be other sensitive information stored in the GPO’s . In the old days, you could change those permissions, to make sure only the right people could read those files. Otherwise, it was a little bit weird that another customer could open those GPO’s from another customer inside a Multi-tenant Active Directory, right?

Before I am going to show you how you could deal with it. Of course, I am not telling you it’s okay to push sensitive information in PowerShell scripts…. But I guess we all know how the cookie crumbles.

So shall we take a look at the AgentExector.log file first? You could find this one, at the same location you could find the other log file (IntuneManagementExtension.log) that also could be storing sensitive information.

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Of course, it’s always best practice to open those kinds of log files with the CMTrace.exe tool I am mentioning in this IMECache blog about troubleshooting the installation of Win32Apps.

Looking at the screenshot above, you can guess what the sensitive information would be!

But do you know what’s kind of funny, a lot of people are only taking a look at those logs on the disk. Why not take a look at the registry? Open the registry and open this key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports\

Please make sure you are selecting the right PowerShell report, by selecting the right GUID.

By opening the “Results” key, you will also notice that sensitive information is also stored inside this key.

And this one, smells like the old-fashioned GPO’s when looking at the ACL!

Afbeelding met tekst

Automatisch gegenereerde beschrijving

So why not export it, as a regular user like shown below?

reg export HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports c:\install\test.reg”

Afbeelding met tekst

Automatisch gegenereerde beschrijving

Open the reg file, and just like with the AgentExecutor log, you would notice the password in it!

2. Fixing the Agent Executor Log.

Now we have seen the fact you don’t want to have sensitive information pushed down to your clients. How are we going to fix it? Of course, this Agent Executor log will log. I guess that’s why it’s called a log.


But if you are dealing with sensitive information, you must beware of the fact that plain text passwords would also be logged in this log. Together with Jos Lieben, we created a nice solution to this problem while creating the LAPS solution.

Our first attempt was adding this part after the password has been changed in the remediation script and of course the detection script.

try{
$intuneLog1 = Join-Path $Env:ProgramData -childpath "Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log"
$intuneLog2 = Join-Path $Env:ProgramData -childpath "Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log"
Set-Content -Force -Confirm:$False -Path $intuneLog1 -Value (Get-Content -Path $intuneLog1 | Select-String -Pattern "Password" -NotMatch)
Set-Content -Force -Confirm:$False -Path $intuneLog2 -Value (Get-Content -Path $intuneLog2 | Select-String -Pattern "Password" -NotMatch)
}catch{$Null}

After some tests, it looks like the command is not executed during the detection or remediation.

So our first attempt to clear the sensitive information failed. But when something fails the first time, don’t give up just make it work better!

We decided to create an additional scheduled task to be run each minute. After we have created this nice addition, we added this to the detection rule. As shown below It will create a new task schedule to launch PowerShell and execute an EncodedCommand each minute!.

Afbeelding met tekst

Automatisch gegenereerde beschrijving

As you look closely, you will notice the -encodedcommand. I just converted the script I had to a base64 key. Beware you will need to specify the UTF-16LE character set!

Base64 Encode and Decode – Online

Afbeelding met tekst

Automatisch gegenereerde beschrijving

It’s obvious you need the have the agentexecutor.log and the intunemanagementextension.log when you need to start troubleshooting so removing only the sensitive information from both log files will be the second-best option. Not the best, as you need to make sure there isn’t anything stored in it, in the first place.

3. Fixing the Registry Reports

Just like with the IntuneManagementextension log, as mentioned earlier those results are also reported in the registry. As showed earlier those registry keys are accessible by everyone so If you didn’t restrict access to the registry, we also need to make sure the sensitive password is removed!

try{
foreach($Tenant in (Get-ChildItem "HKLM:\Software\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reports")){
foreach($script in (Get-ChildItem $Tenant.PSPath)){
$json = ((Get-ItemProperty -Path (Join-Path $script.PSPath -ChildPath "Result") -Name "Result").Result | convertfrom-json)
if($json.PreRemediationDetectScriptOutput.StartsWith("Password does")){
$json.PreRemediationDetectScriptOutput = "REDACTED"
Set-ItemProperty -Path (Join-Path $script.PSPath -ChildPath "Result") -Name "Result" -Value ($json | ConvertTo-Json -Depth 10 -Compress) -Force -Confirm:$False
}
}
}
}catch{$Null}

As shown above, I am removing the sensitive parts from the registry key instead of removing the whole key. Because do you know what happens when you remove the whole reporting key? You are speeding up the proactive remediations and you will end up with that same sensitive information back in your registry and the whole process will start over, over and over again

Just like with the Intune Management Extension log you could add this part to the Task Schedule which was also removing the password in the log file. Just add the 2 parts together and convert it to a Base64

Conclusion:

Please make sure you are not putting sensitive information in your PowerShell scripts ever. But if you have no other choice, please make sure you clean up the mess afterward

Spaceballs Password GIFs | Tenor

Leave a Reply

Your email address will not be published. Required fields are marked *

5  +  2  =