{ "id": "75251ca1-373a-4de3-8cbc-b5154b1059d3", "created_at": "2026-04-06T01:30:37.862188Z", "updated_at": "2026-04-10T03:20:31.841315Z", "deleted_at": null, "sha1_hash": "38cfb2c9a861091a196ff3da8fb8287c6f0f324d", "title": "Kansa: Service related collectors and analysis", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 295199, "plain_text": "Kansa: Service related collectors and analysis\r\nBy davehull\r\nPublished: 2014-05-03 · Archived: 2026-04-06 01:00:18 UTC\r\nIn my previous post on Kansa's Autoruns collectors and analysis scripts, I mentioned that the Get-Aurounsc.ps1\r\ncollector relies on Sysinternals' Autorunsc.exe to collect data on all of the Autostart Extension Points (ASEPs) that\r\nit has catalogued. Autorunsc and its GUI sibling, Autoruns, are great tools, but they are not comprehensive, there\r\nare other ASEPs that they don't catch, so Kansa includes a few additional modules that aim to collect additional\r\nASEPs and additional data about ASEPs.\r\nGet-SvcAll.ps1\r\nRuns Get-WMIObject win32_service to collect details about all services. Output is saved as XML. Some of this\r\nsame data is collected by Get-Autorunsc.ps1 above, however, this will pull additional properties for each service\r\nwith some of them being specific to the type of service. If a service is running, you'll get its process id and the\r\ncontext it runs under (Local System, Local Service, etc.). There's even an InstallDate property, which is\r\nawesome, however, in my experience, it's never populated, which sucks.\r\nFor analysis of the data collected by Get-SvcAll.ps1, there are two very basic frequency analysis or stacking\r\nscripts as of this writing. They are Get-SvcAllStack.ps1 and Get-SvcStartNameStack.ps1. The former does its\r\nfrequency analysis based on Service \"Captions\" and Pathnames. The Captions are the short friendly names you\r\nsee when you look at the Services running on your system while the Pathnames include the path to the binary\r\nand any arguments. Here's an example from two systems where the Application Identity service has two\r\ndifferent sets of command line arguments:\r\nClick for larger image\r\nStacking by these properties across many hosts shows investigators services that may have the same Caption, but\r\ndifferent binaries and arguments. This same kind of analysis is available in the Autoruns stacking scripts with the\r\nadded benefit of stacking by file hash (e.g. MD5).\r\nGet-SvcStartNameStack.ps1 stacks by Caption and StartName, the latter of which turns out to be the name of the\r\naccount the service runs under.\r\nAnother Service analysis script, but not a stacker, is Get-SvcAllRunningAuto.ps1, which pulls the list of Services\r\nthat were in a running state or set to start automatically when the Get-SvcAll.ps1 collector ran on the targets.\r\nASEPs not collected by Autorunsc:\r\nAs I mentioned above, Sysinternals' Autoruns and Autorunsc executables collect all the ASEPs they know to\r\ncollect, but that is not the universe of ASEPs.\r\nhttps://trustedsignal.blogspot.com/2014/05/kansa-service-related-collectors-and.html\r\nPage 1 of 4\n\nWindows Services can be configured to recover from failures. In my experience, restarting the service is the most\r\ncommon recovery option, but one option that adversaries can use is the \"Run a Program\" option as shown below:\r\nClick for larger image\r\nIn the screen shot above, the Application Identity service is configured with a failure recovery response that will\r\nrun a program called ServiceRecovery.exe from C:\\ProgramData\\Microsoft\\ with the command line argument -L\r\n443. This is a persistence mechanism that Autorunsc won't capture.\r\nKansa's Get-SvcFail.ps1 collector will collect service failure recovery information from all services. Kansa\r\nincludes a few analysis scripts that will stack the service failure recovery data, but the most useful one is Get-SvcFailCmdLine.ps1, which returns the frequency count of the program and command line parameters from all\r\nthe collected service failure information. The image below shows this data from a few thousand systems:\r\nClick for larger image\r\nIn the example there are 129769 Service Failure entries, 75088 of them have the same program and command line\r\narguments configured as a recovery option. Seems unlikely this is malicious.\r\nhttps://trustedsignal.blogspot.com/2014/05/kansa-service-related-collectors-and.html\r\nPage 2 of 4\n\nIn another smaller data set, the following data was returned:\r\nClick for larger image\r\nI include this screen shot because I've run into the customscript.cmd entry in multiple data sets and in all the cases\r\nI've investigated, I've not yet found a service that referenced customscript.cmd anywhere in the Services GUI, but\r\nyou will see services reference it in the data of their Registry key values, like the following:\r\nI've also searched file systems on hosts where I've seen this, but I've not found a file on disk called\r\ncustomScript.cmd. I wanted to mention it here in case you run across it. If you do see a reference to\r\ncustomscript.cmd that includes a path, you may have an adversary attempting to blend in with a common value.\r\nThe last Service related collector in Kansa, as of this writing, is Get-SvcTrigs.ps1, which collects another set of\r\nASEPs that Autoruns does not collect, yet -- Service Triggers. Service Triggers are new with Windows 7 and later\r\nversions of Windows. They allow Windows Services to have more startup flexibility than the old Manual and\r\nAutomatic startup modes. Now services can respond to the presence of specific hardware, group policy changes,\r\nnetworking events, etc. More information about Service Triggers can be found at the following links:\r\nhttp://msdn.microsoft.com/en-us/library/windows/desktop/dd405513(v=vs.85).aspx,\r\nhttps://trustedsignal.blogspot.com/2014/05/kansa-service-related-collectors-and.html\r\nPage 3 of 4\n\nhttp://blogs.windows.com/windows/archive/b/developers/archive/2009/10/26/windows7-trigger-start-services-part-1-introduction.aspx\r\nhttp://blogs.windows.com/windows/archive/b/developers/archive/2009/10/27/windows7-trigger-start-services-part-2-building-a-trigger-start-optimized-service.aspx.\r\nKansa includes a basic stacker for Service Triggers. Interpreting the data to determine what's normal and what's\r\nsuspicious can be daunting and tedious. Searching on GUIDs can be of some help. Below is a frequency listing of\r\nService Triggers from a relatively small sample, two systems.\r\nClick for larger image\r\nI have Service Trigger data from a few thousand machines, but I'm not at liberty to share it here, trust me when I\r\nsay finding outliers is easier with a larger data set, but keep in mind, just because something is an outlier doesn't\r\nmean it's bad and the inverse is also true, just because something is common, it's not necessarily good.\r\nThere is one more ASEP that I know of that Autoruns won't catch, but that Kansa collects, but I'll save that for\r\nanother post.\r\nSource: https://trustedsignal.blogspot.com/2014/05/kansa-service-related-collectors-and.html\r\nhttps://trustedsignal.blogspot.com/2014/05/kansa-service-related-collectors-and.html\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://trustedsignal.blogspot.com/2014/05/kansa-service-related-collectors-and.html" ], "report_names": [ "kansa-service-related-collectors-and.html" ], "threat_actors": [], "ts_created_at": 1775439037, "ts_updated_at": 1775791231, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/38cfb2c9a861091a196ff3da8fb8287c6f0f324d.pdf", "text": "https://archive.orkl.eu/38cfb2c9a861091a196ff3da8fb8287c6f0f324d.txt", "img": "https://archive.orkl.eu/38cfb2c9a861091a196ff3da8fb8287c6f0f324d.jpg" } }