Script history disappears when script is deleted!

This is probably more of a feature request, but I can’t believe it’s not already there…

I just noticed that when I delete a script, it also deletes all the runs of that script from the script history in the Asset. Is there anywhere else this history can be accessed, or is the evidence that a script was run on an Asset simply gone?

I know others have suggested adding an Alert or writing to a Custom Field to track scripts, but I’m thinking more about a malicious script run by a disgruntled employee or hacker, who aren’t likely to be kind enough to add a tracking line to their scripts. Surely Syncro has some way to track at least the fact that a script was run??!?

3 Likes

I had noticed this too a while back. We brought it to supports attention, for very similar reasons and were told the issue was being raised with development. The Tech seemed to think this was not as intended behavior.

Never did hear back about that, so thanks for the reminder.

1 Like

Create your own event log and always write a record of your scripts to the event log on the machine. I do this for various reasons and I use lets say event ID 5 for success, 10 for failures, etc.

2 Likes

If a hacker or disgruntled employee is writing a malicious script, I cannot see them recording in the event log of the endpoint that the script ran.

Really surprised like others this isn’t in situ like others have suggested if something malicious happens they aren’t going to write to the event log and then the history’s gone.

Usually when I retire a script, I just prepend it with ZZ_ or something so that it is at the end of the list and just take it out of any categories/favorites, etc.

Decent workaround for those who want to keep the script history when they knowingly delete a script, but it’s not likely that a malicious actor will just “retire” their script rather than delete it to cover their tracks.

Create your own event log, write a record of scripts to it?
What evil sorcery is this?
We can do that? Pray tell, to those of us who only THINK we know scripting…

New-EventLog (Microsoft.PowerShell.Management) - PowerShell | Microsoft Learn New-EventLog, Write-EventLog, etc.

I do agree this is quite ridiculous and no one is going to maliciously write to the event log. It seems like every day I try to perform functionality, almost regardless of the feature in Syncro and I’m smashed into some limitation that we ALL must build our own workarounds for. Is it also accurate that we can only see roughly the last 30 runs of scripts on any given asset? I just noticed I needed to see what a script ran/output from 5/8 on an asset and I see zero ways of getting this data out of the scripts page for the asset. I have an automation that normally runs a wiztree/disk space script and doesn’t look like it ever ran one and I can’t see any history.

I’ve ran multiple reports and none that I’ve seen have this data, I’m not sure if it’s gone or hidden somewhere. This seems so basic, we can’t get any information on if scripts are failing, how often they have been failing. And with that, the more daily scripts I have run on assets, the harder it is to see previous data/information. And if I then put the data in the asset activity from a script (Like we do with our nightly reboot script), it then floods that full of reboot activity at a quick glance.

1 Like

It would be nice if we had a central repository for all these hacks and workarounds that users have setup to make basic things happen that Syncro doesn’t do. I follow the Facebook forum religiously, but the search there and in this Community is lacking for finding previous answers.

Its part of a multitude of issues with the way Syncro works on some things.
For example, you can’t archive an asset or contact - Then when you delete the asset the linked asset just removes itself from tickets rather than leaving the placeholder for the asset.

Crazy!

We have a category called Archived we tag them with.

1 Like

There are a few topics here, but on the point of security and bad actors, this would be killed by 2FA on script changes.

I agree, deleting a record should leave the placeholder behind for historical records. It’s like we are expected to never have to reference those records again. Might as well delete the ticket too since the content can’t be searched :stuck_out_tongue:

No it wouldn’t.
The MFA Syncro uses is based on the Google Authenticator, and if a tech’s phone has already been hacked prior to scanning the QR code, then it is possible for the bad actor to obtain the QR code image and add it to their MFA app as well. This is because the Google Authenticator allows multiple devices to scan the QR code into their MFA apps.

Most compromises come well after establishment, so a scenario like that is extremely unlikely. There always has to be a balance between functionality and security.

By that count, most MFA is useless because they all use the same kind of system which allows you to use almost any MFA authenticator with them. I stopped using the Google one years ago.

If the QR code is compatible with the Google MFA, then it doesn’t matter which app you use, the same problem applies.
Of course, if the bad actor has compromised your phone, then they can access the MFA app and read the code anyway. There has been Android trojans that have been able to do this since 2019.
It is these sorts of reasons that make it imperative that Syncro implement locking the Admin account access to specific IPs, and an accessible and immutable audit log.

Can you use any MFA app with the Microsoft MFA push notifications that require a 2 digit number to be typed into the Microsoft Authenticator app?

Regarding Syncro Security controls:

Microsoft 365 AAD (Entra) SSO would be my suggestion. Microsoft has put a lot of time and effort into security and continues to do so. Microsoft probably put more effort into AAD security controls than Syncro has put into the entire product since the beginning of time. There are all kinds of security controls, monitoring and alerts in AAD (Entra) that developers like Syncro could never come close to implementing. Let’s use the best tools out there and not re-invent the wheel.