This blog will show you how to deal with Sensitive Information (such as passwords) that could end up in the Intune Management Extension’s Agent Executor Log files. Some time ago, I wrote a blog about implementing LAPS with Intune using Proactive Remediations.
https://call4cloud.nl/2021/05/the-laps-reloaded
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.
1. What is stored inside these logs?
As mentioned in the introduction, sensitive information could be stored inside those logs. Those log files are just like the old GPOs, which 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!)
Luckily, the “connect as” issue from the picture above was fixed a long time ago, but other sensitive information could still be stored in the GPOs. 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 GPOs from another customer inside a Multi-tenant Active Directory, right?
Before I 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 can find this one, and at the same location, you can find the other log file (IntuneManagementExtension.log), which could also be storing sensitive information.
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
Of course, it’s always best practice to open log files with the CMTrace.exe tool I mentioned in this IMECache blog post about troubleshooting the installation of Win32Apps.
Looking at the screenshot of the agentexecutor.log above, you can guess what the sensitive information is!
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 ensure you select the right PowerShell report by selecting the right GUID.
When you open the “Results” key, you will also notice that sensitive information is stored inside it.
And this one, smells like the old-fashioned GPO’s when looking at the ACL!
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”
Open the reg file, and just like with the AgentExecutor log, you will notice the password in it!
2. Fixing the Agent Executor Log.
Now, we have seen that you don’t want 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 that plain text passwords will also be logged in this log. We created a nice solution to this problem with Jos Lieben while creating the LAPS solution.
Our first attempt was to add this part after the password had 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!.
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
It’s obvious you need 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. It’s not the best, as you need to make sure nothing is stored in them 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 the whole key. Do you know what happens when you remove the whole reporting key? You speed 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 and over again.
https://call4cloud.nl/2021/05/the-laps-reloaded/#third-part
Just like with the Intune Management Extension log, you could add this part to the Task Schedule, which also removes the password in the log file. Just add the two parts together and convert it to a Base64
Conclusion:
Please make sure you are not ever putting sensitive information in your PowerShell scripts. But if you have no other choice, please make sure you clean up the mess afterward.
