[ad_1]
Most DFIR and SOC analysts are conversant in the Run keys as autostart areas inside the Home windows Registry:
[HKLM|HKCU]SoftwareMicrosoftWindowsCurrentVersionRun
Values beneath these keys are robotically run asynchronously upon system begin and consumer login, respectively. That is one thing we have know for some time, and we have dutifully included these autostart areas into our “indicators of program execution” artifact class.
It seems, which will not be the case.
Wait…what? Did I simply say {that a} worth listed in one of many aforementioned Run keys could not, actually, be executed at system begin or consumer login??
Sure…sure, I did.
Let’s first begin with validating that the entries themselves have been run. We all know that we are able to parse the Microsoft-Home windows-Shell-Corepercent4Operational Occasion Log, extracting occasion ID 9707 and 9708 occasions to see when execution of the values beneath the Run (and RunOnce) keys was began, after which accomplished (respectively). We are able to use no matter device we wish to open or parse the Home windows Occasion Log file, and the filter by way of it to see that, sure, on this date, presently, these entries have been, actually, launched. That is an effective way to validate our findings, primarily based on the entries within the Run key.
It occurs that there is one other set of Registry keys at play:
[HKLM|HKCU]SoftwareMicrosoftWindowsCurrentVersionExplorerStartupApprovedRun
If you happen to navigate to the above key, you will see that the worth names inside the important thing mirror the worth names beneath the corresponding Run key, however that the info is completely different. Determine 1 illustrates the info from one in all my methods.
 |
| Fig 1: StartupApprovedRun key values |
As you see in determine 1, the worth names mirror entries within the Run key, however the values all have completely different knowledge. First, the binary knowledge for every values is 12 bytes in size. If the primary 4 bytes (DWORD) is 0x02 or 0x06, then the corresponding worth within the Run key’s enabled. If the primary DWORD is 0x03, then the worth is disabled, and the remaining 8 bytes (QWORD) is the FILETIME object representing the info and time that the worth was disabled. Determine 2 illustrates this knowledge parsed by way of RegRipper Professional:
 |
| Fig 2: RegRipper rundisabled.pl plugin output |
Now, this is the kicker…what you see in figures 1 and a couple of mirror what occurs if the values are disabled by way of the Startup tab in Job Supervisor. If you happen to use RegEdit or reg.exe to navigate to the Run keys, you may merely delete entries to forestall them from executing. Nevertheless, for those who use the Job Supervisor Startup tab to enumerate startup entries, and also you disable entries which can be discovered within the Run keys, you see what’s illustrated in figures 1 and a couple of.
What’s actually fascinating about this StartupApproved Registry key’s that there is one other subkey:
[HKLM|HKCU]SoftwareMicrosoftWindowsCurrentVersionExplorerStartupApprovedStartupFolder
As you might need guessed by the title, this is applicable to the Startup folder within the file system. Sure, MS has added Registry key that, if there are entries within the corresponding Startup folder, there may even be a StartupFolder key what accommodates worth names that mirror these entries. On methods the place there are not any entries within the Startup folder for the account, I’ve not discovered a corresponding StartupFolder key.
Determine 3 illustrates what this seems to be like by way of RegRipper Professional.
 |
| Fig 3: Disabled StartupFolder entry, by way of RegRipper Professional |
If you happen to use Job Supervisor to re-enable the values, the info for the corresponding entry beneath the StartupApproved key’s modified again to the “enabled” worth (first DWORD = 0x02, remaining QWORD all 0s).
At this level, the takeaway is, relatively that simply checking the Run key, correlate the entries the worth knowledge inside the StartupApprovedRun key, and validate each by way of the corresponding occasion IDs within the Microsoft-Home windows-Shell-Corepercent4Operational Occasion Log.
However wait, there’s extra!
If the entries within the Run key have been as an alternative disabled by way of Autoruns, one thing completely completely different occurs. If a worth is disabled beneath the Run key, then when Autoruns is closed, an AutorunsDisabled subkey is created beneath the Run key, and the disabled worth is moved to that subkey. If an entry beneath the Startup folder is disabled by way of Autoruns, an AutorunsDisable subdirectory is created beneath the Startup folder, and the entry (shortcut, executable, batch file, and so forth.) is moved to that subdirectory.
So What?
Why does any of this matter? Properly, first off, it signifies that if we assume that simply because there’s an entry in a Run key, that the appliance pointed to was truly executed, we could also be improper. If something, this reinforces the necessity to validate and appropriately perceive findings and artifacts.
How might this be used? Properly, one thought is {that a} menace actor might create a distraction; by placing an entry in a Run key after which disabling it within the corresponding StartupApprovedRun key, admins and analysts is likely to be caught unaware and pursue a line of study that really takes them down a rabbit gap, and trigger them to not examine the actual situation.
Suppose that is a bit far fetched? I’ve seen it occur.
[ad_2]
Source_link