Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


rookie last won the day on August 19 2019

rookie had the most liked content!

Community Reputation

7 Neutral

My Information

  • Location
    Dallas, TX
  • Agent Count
    1500 - 2000 Agents

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If anyone needs the registry mitigation I put this together w/ some helpful error output and filtering. Script notes should suffice to figure out what's it's doing, enjoy! Try { ## Verify this is a server OS before continuing $serverCheck = (Get-CimInstance Win32_OperatingSystem).Caption If ($serverCheck -notlike '*Server*') { $fail = $True Write-Warning "This mitigation is only intended for Servers and this machine is running $serverCheck, unable to apply mitigation." } Else { ## Check to see if the DNS role is active so we don't make registry changes on machines that don't need them $dnsRoleCheck = (Get-WindowsFeature DNS).Installed If ($dnsRoleCheck -ne 'True') { $fail = $True } } } Catch { $fail = $True Write-Warning "$env:COMPUTERNAME failed to check for the DNS role install status." } ## If the script confirmed this has the DNS role, apply the mitigations If (!$fail) { ## Set reg path we'll be working from $regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters" Try { ## If the TcpReceivePacketSize DWORD value doesn't exist in registry, create it If (!(Get-ItemProperty -Path $regPath -Name TcpReceivePacketSize -EA 0)) { New-ItemProperty -Path $regPath -Name TcpReceivePacketSize -Value 0xFF00 -PropertyType DWORD | Out-Null $restartDNS = $True Write-Output 'Applied SIGred CVE-2020-1350 DNS registry mitigation' } ## If the TcpReceivePacketSize DWORD in registry doesn't have the 0xFF00 value for the mitigation, update it to 0xFF00 If (((Get-ItemProperty -Path $regPath -Name TcpReceivePacketSize -EA 0).TcpReceivePacketSize) -ne 65280) { Set-ItemProperty -Path $regPath -Name TcpReceivePacketSize -Value 0xFF00 | Out-Null $restartDNS = $True Write-Output 'Registry mitigation for SIGred CVE-2020-1350 DNS was present, but had the wrong value. Set value to 0xFF00' } } Catch { $fail = $True Write-Warning "Failed to create or update the registry key at $regPath, mitigation have not been successfully implemented." } ## If changes were made to DNS in registry, restart DNS services Try { If ($restartDNS) { Restart-Service DNS Write-Output 'Restarted DNS services' } } Catch { $fail = $True Write-Warning "Failed to restart DNS services. DNS Services must be restarted in order for this mitigation to apply." } } ## Final output of success/fail If ($fail) { Write-Warning "!FAILED: Failed to apply mitigations for SIGred CVE-2020-1350. `r`n`r`nVerbose error output: $Error" } Else { Write-Output '!SUCCESS: Successfully applied mitigations for SIGred CVE-2020-1350' }
  2. @Joe.McCall nice, good to hear. Yeah I might change it just for OCD sake at some point haha. @Namik Thanks! No problem!
  3. Ahh thanks man. This is fixed. On the Name one I usually do `Name` but when I SQLSpy'd the inject for a monitor from Automate it was just Name and not `Name` so I just directly copied/adapted it /shrug
  4. Yeah @HickBoy it's sounding like everyone hosted isn't able to run this...weird. Anyway, adding that comma before the group ID will not work...that group ID is the first value so would be no comma since the comma is the separator to define multiple different values for different columns. Okay @Namik make an EXE monitor and use this line... "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command "& {(new-object Net.WebClient).DownloadString('https://raw.githubusercontent.com/dkbrookie/Automate-Public/master/CVE/CVE-2019-1182/Powershell/CVE-2019-1182.ps1') | iex}" See the rest of the settings here in this screenshot: https://gyazo.com/208dd0394e75eef7ec202553da7a126f Nice! Will test this out, thanks @chris_bb! ❤️ you bigwoof @bigdog09 -Rookie
  5. Hey all, I've been active in the community for a few years now but have never really posted in the forums. I've put together a script/remote monitor to address the latest RDP vulnerability from Microsoft and figured I've learned enough from the MSPGeek community it can't hurt to give some back. This first link is a SQL inject that will create a remote monitor on your "Service Plans\Windows Servers\Managed 24x7" and "Service Plans\Windows Workstations\Managed 8x5" groups. What groups it installs the monitor on are just defined on the inject with the GroupID so if you just look at the inject it's easy to change that GroupID to whatever you want before you run it. !!!WARNING!!!! - You're running a SQL inject on your DB...this can be dangerous, proceed at your own risk. Read through the inject, make sure you're comfortable with what it's doing. This monitor is also live pulling a powershell script from MY github. This means if I decided to have a bad day and change the powershell script in my github to something malicious then I could effectively run my malicious code on ALL of your machines. I'm not malicious, but ya know...be smart, be safe! Feel free to host the powershell script at your own location and just swap the URL on the monitor. Lastly, I've tested this on several machines in my environment, but that doesn't mean there can't be an issue I haven't ran into yet. If you find a problem, let me know so I can fix it! Download Links SQL Inject: https://github.com/dkbrookie/Automate-Public/blob/master/CVE/CVE-2019-1182/SQL/CVE-2019-1182_Remediation.sql Powershell: https://github.com/dkbrookie/Automate-Public/blob/master/CVE/CVE-2019-1182/Powershell/CVE-2019-1182.ps1 Script breakdown... This script is outputting either !ERROR:, !WARNING:, or !SUCCESS: with details on the state of the install process. If you set the monitor alert template to create a ticket (I have it set to Default - Do Nothing so just change to what you want) it will output the Powershell results right into the ticket. The keywords from the script output above are to use in a state based remote monitor in Automate so this will go through what that looks like briefly. The script checks the OS of the machine and figures out the correct KB number it needs to have installed to patch this vulnerability. Once it finds the right KB, it checks to see if the KB is installed or not. If it's not installed, it will install it with no reboot so this is safe to run mid-day. That means right from the monitor CHECK it is actually installing the remediation, so there is no separate script attached. The patch download/install is all self contained in the monitor check itself. !FAILED: will only output if the machine is eligible to receive the CVE-2019-1182 patch and something in the script actually failed and needs attention !WARNING: will only output if the machine is not eligible for the CVE-2019-1182 patch. The reason I've chosen the all managed servers/workstations groups is so you can highlight all of the machines quickly/easily in WARNING state that do not have this patch available to them. This would be a good time to use this as leverage to get your clients to upgrade some machines !SUCCESS: will only output if the patch has been verified to be installed Monitor breakdown... The monitor will be named "CVE-2019-1182 Remediation" The monitor runs every 4hrs but you can change this to whatever you want FAILED state: Looks for the keyword "!ERROR:" from the powershell output WARNING state: Looks for the keyword "!WARNING:" from the powershell output SUCCESS state: Looks for the keyword "!SUCCESS:" from the powershell output Enjoy! -Rookie
  6. @ATrotterYou just need to run your command from `console shell` on the proper console number so the popup displays on their desktop. If you just run default Automate commands it's going to send that popup to the `system` desktop....so obviously the user will never see it. The key here is %consolenumber%, which will be the console number of the logged in user. %consolenumber% will not have a value until you GET the value though, so here is what you need to do... Use the script function "IF Console Logged On". Leave the username blank, then tell it what label to go to if a user IS logged in like :loggedOn After your :loggedOn label, insert another line and use the script function "Console Shell", put your command in the command text box, then fill out the Console Number box with %consolenumber% (which now = the console number of the user detected to be logged in from step 1) That's it! I use powershell popups quite a bit like this.
  7. Thanks @DarrenWhite99. I reached out to my account rep and opened a ticket right before I found the work around and on the support ticket they just sent me this update... I'll update when I know more.
  8. Eh...I'd say the majority of the content on this forum are features / fixes / additions everyone wants LT to implement and they haven't yet so holding information from a community created only to share it seems a little silly
  9. I figured this out -- you can skip the FIPS check in the LT config files. 1. Open Notepad as admin and open these 3 files... C:\Windows\LTSvc\LTSVC.exe.config C:\Windows\LTSvc\LTSvcMon.exe.config C:\Windows\LTSvc\LTTray.exe.config 2. Add the following bit inside your <configuration> </configuration> brackets in all 3 files above... <runtime> <enforceFIPSPolicy enabled="false"/> </runtime> So it would look like this for LTSVC.exe.config for example... <?xml version="1.0" encoding="utf-8" ?> <configuration> <runtime> <enforceFIPSPolicy enabled="false"/> </runtime> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> <supportedRuntime version="v2.0.50727"/> </startup> </configuration> 3. Save / close / restart LT services / enjoy
  • Create New...