Persistence
Now that we know about persistence on domain and domain controller levels, why bother with SQL Server? Most detective controls are implemented at the OS level. Database audits are not so common and thorough. A SQL Server service account may have extensive permissions on the OS, giving an attacker an excellent hideout, as all questionable actions will be logged as they were performed by the service account. Lastly, even if auditing and monitoring are enabled on busy databases, it is difficult to differentiate legitimate activities from malicious ones. We will start with the most noisy and unsafe way to achieve persistence at the OS level via autoruns, moving toward the SQL Server level, with startup procedures and triggers.
File and registry autoruns
These two methods are very OpSec-unsafe, as the Startup folder and registry keys are often monitored by security solutions, such as Sysmon and EDR. There is a slight chance that writing a file in such locations using a...
