Practical techniques for leveraging SIEM as an offensive discovery tool, helping defenders think like attackers to strengthen security from within.

See above - queries.md file.

We dont spare any queries and are releasing all so some new queries added ~ 18-19 september 2025. Schtasks related with split for binary/argument, and system/administrator user and other event code for Schtasks.

Queries added for Vulnerability Management in file: vulnerabilitymanagement.md

We hope that you liked the presentation. Ping us if you (i would say when you) find vulnerabilities by using this method. A simple message like "one of your queries cathed good stuff".. is more then enough :) do it by commiting to the ping.md file or contact us in alternative ways! We would be happy to share your success!

The repo will assist you in having offensive mindset.

Repo is to share the material and queries that we talked about in our presentation:

⭐ https://www.youtube.com/watch?v=5nfL_4ek4dY

We have included the most interesting ACL related parts and have tips & tricks.

Check out the outstanding webinars about windows local privilege escalation and windows endpoint misconfigurations which will assist you further on. There are more areas to look into.. This is only the starting point. If you build good queries in other areas - please share it with us so more in the community can use them.

The queries with ⭐ mark is extra highly relevant. The topics down below with ⭐ is really good content.

a must to watch, specially the ACL for binaries, services and schedule tasks.

• https://www.youtube.com/watch?v=EG2Mbw2DVnU

Topic 2 (Insecurely installed/conf Software) And Topic 5 (Insecure Services And Tasks)

• https://go.spenceralessi.com/windowsmisconfigsreplay

• https://www.youtube.com/watch?v=JWopwNVP_to

• https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Windows%20-%20Privilege%20Escalation.md
• https://sushant747.gitbooks.io/total-oscp-guide/content/privilege_escalation_windows.html
• https://www.absolomb.com/2018-01-26-Windows-Privilege-Escalation-Guide/

• weak passwords in command_line - that are not following best practices / policies
• weak passwords or sensitive information in powershell admin scripts scriptblock event code: 4104. Search for strings: "SecureString","PSCredential","Password", "passwd"......
• weak passwords in registry - that are not following best practices / policies
• AlwaysInstallElevated in Registry, Autologons
• Windows Privileges - Look at 4672 (logon with special privileges) And 4704/4705 (assignment/removal of rights)
• Event code 5136 and 5137, AD objects.. look in to the fields: description, info and adminComment, if they have any plaintext passwords.
• Do not assume that Program Files and similar admin-protected directories always have correct ACLs (Access Control Lists). It does happen that applications set incorrect default permissions and are far too permissive. CWE-732, CWE-284, CWE-276
• etc..

• Search in webserver logs for parameters (language=en.html) that shows file inclusion to test for LFI/RFI
• Search for application logs for SQL related errors that shows errors on bad charachters..
• AD attributes (example event.code:"5136" and Attribute:"msDS-KeyCredentialLink") that are commonly abused. Find misconfigurations and harden AD.
• Linux etc.. etc..

• https://www.securit360.com/blog/securing-windows-common-misconfigurations-that-give-attackers-the-advantage/
• https://offsec.blog/hidden-danger-how-to-identify-and-mitigate-insecure-windows-services/
• https://www.youtube.com/watch?v=EG78PbCMWpY

Make a process creation query using event.code 1 from SYSMON OR event.code 4688 (or the event.codes for services, schedule tasks, DLL load from C-root subfolders) Look for applications that are installed in C:\ root drive

      C:\myapplication\myapplication.exe
      C:\myapp\subfolder\myapp.exe
      C:\SoftwareCompany\software.exe
      C:\myapplication\myapplication.dll
      C:\myapp\subfolder\myapp.dll
      C:\SoftwareCompany\software.dll

The issue with applications that are installed in C-root folder is that it has per default incorrect ACL permissions which allows Authenticated Users to modify (M) the folder and possibly its files. If the Software installation does not correct the ACL in the installation process will likely result in a privilege escalation (confirm it) if a service or another high privileged process is spawning (ex. myapplication.exe OR myapp.exe) from one of the installation paths in C-roots subfolder.

Gives you an idea of which event codes to use what you will see in the event code it self.

• https://detect.fyi/threat-hunting-suspicious-windows-service-names-2f0dceea204c

Gives you and idea of which event codes to use and what you will see in the event code it self.

• https://www.thedfirspot.com/post/evil-on-schedule-investigating-malicious-windows-tasks

Well configured SYSMON config to catch events that are of interest, like event.code 1, 7, 11.

• https://github.com/SwiftOnSecurity/sysmon-config
• https://github.com/olafhartong/sysmon-modular

Enabled Advanced auditing for some of the Windows events. For an example, process creation 4688 will likely need it to catch parent process name and not only the parent pid.

Scheduled task - 4698 is not enabled by default.

Access Control List (ACL) attributes define what actions a user or group can perform on files or folders.
Here are some key ones worth noting:

You may need to do some whitelisting (see below for typical paths in ProgramData). The idea is to query typical user writable paths but it happens that the (files or folders) have correct ACL set. If offensive mindset does not help to escalate privileges - whitelist them. Filter out the less interesting ones: the ones with correct ACL, randomized file.names (filter out the folder). We want to reduce the noice and have a baseline. Its important to do this after verifying that its not a vulnerability. So you dont miss a Scheduled task that is vulnerable on every client.

You will likely need to whitelist the queries. Make your hunt, fine tune the queries and make alerts of them to catch new events that you have not looked into.

  C:\ProgramData\Microsoft
  C:\ProgramData\Package Cache
  C:\ProgramData\Packages
  etc.

Other ones that may need whitelisting, which may be common, is hardware related drivers and similar stuff that has randomized names..

Dont forget to query in the timespan of your "Log retention period". A good Methodology is to query in the beginning a short time frame which is progressivly increasing.

1. 1 day
2. 1 week
3. 2 weeks
4. 1 month
5. 2 months
6. etc..

Do you hunt and check the interesting ones and fine tune and whitelist.. in the end make alerts of them to catch new events..

If a binary replacement is not possible because of correct ACL. Check folder permissions and if you have permissions to write files check if the executable tries to load any dlls that do not exist. If so, create them and you have your code execution. If binary replacement is not possible because its a running process. Check possible DLL sideloading or check if you as a regular user have permissions to restart the service it self. Another way is to check if you as a regular user can perform a "shutdown" that you escape in last second. A shutdown initiation stops processes and if you break out from it, you may be able to replace the binary of the terminated process. If the service is in Autostart mode and you dont have permissions to start/stop the service, what you can check is if you have SeShutdownPrivilege and if so initiate a reboot with shutdown /r /t 0.

If a service is spawning the process and if its not possible to replace binary, the binary does not try to load any missing DLLs. Dont give up - maybe the path is unquoted and you have write permissions and you can use that?

Build your queries layer on layer.. so check for service/schedule task creations, check for the process creation with parent as services or schtasks. Its possible that some system creates the service or schedule task but the binary path etc does not exist and the process creation never happens. But the vulnerability is still there.

To reduce query load (performance) and probably whitelisting.. it may be a good idea to have queries separated for clients/servers. So a set of queries only used for the client endpoints and same set used for server endpoints.

The generic process creation by SYSTEM is high value query. It catches alot of scenarios.. besides of services and schtask spawning child processes it also catches msiexec.exe spawning a child process. It also caches if a executable from c:\windows\ccmcache is spawning a child process from a userwritable path. If we where to order executables in vulnerability i would still say that services.exe is related to software misconfigurations and schtasks is more a administrator misconfiguration..

If you have tried all queries and did not got successful. if you want to hunt deeper, and do a litte bit more work - go for every child process of services.exe and schtasks.exe, regardless of where. Enumerate the enterprise and look for the ones in typical admin protected paths also (Program Files & Program Files (x86)). Its more common than you think that software vendors mess up the ACL even in typical protected paths. Use the process creation events and the events for services and schedule tasks. For Schedule tasks - query every Command field and Argument field. The argument field may be pointing to a script file in user writable path or C-root. The command fields may be pointing to a binary that has insecure ACL.

Its likely that if a user can trigger an installation, they can also trigger a uninstallation. Uninstall processes are of interest regardles of where the filepath is. If the ACL is not correct - a binary replacement will likely cause trouble. Query also for file creation of typical uninstall files by using Sysmon event.code:11. We want to do this to catch every uninstaller without trusting the process creation events. This is because its not common that users actually do uninstallation of installed applications.. They just dont care about that and therefor it will be easier to miss some uninstall events that exists but never are triggered.

      uninstall.exe – Most generic and widely used.
      unins000.exe, unins001.exe – Common with Inno Setup installers.
      unwise.exe – Often used by older Wise Installer packages.
      uninst.exe – Shortened version, often found in legacy software.
      uninstaller.exe – Slightly longer, descriptive variant.
      remove.exe – Sometimes used for minimal installers.
      setup.exe (with /uninstall or /remove parameter) – Some apps reuse the installer executable for uninstallation.
      appname_uninstall.exe (e.g., chrome_uninstall.exe)
      update.exe (with --uninstall) – Seen with apps like Slack or Discord using Squirrel installers.

      *_uninstall.exe – Many apps prepend the app name, e.g., teams_uninstall.exe, zoom_uninstall.exe.
      *_cleanup.exe – Removal tools often have cleanup variants, e.g., driver_cleanup.exe.
      *_remover.exe – Another common AV/vendor naming style.

To show you how common it is with misconfigured third party software.