How to add a "Shutdown" folder (the opposite of the "startup" folder) ?

"Jeff Barnett" wrote:
Assume that a malicious code somehow enters your system. It simply puts
itself on the "shutdown list" if there is such an entity. At shutdown it
puts itself on the startup list(s). At next startup, it does what it
wants then removes itself from the startup list(s) and adds itself to
the shutdown list. Since we seem to have no way to examine the shutdown
list, this code remains hidden from sight. That is unless you know how
to use some utilities unknown to the vast majority of us.

I've never seen any use of a "shutdown list" by malware in my years of
dissecting samples. When malware first runs it may set itself to run
from the startup folder, autorun.ini or set one or more of the many
registry entries that specify programs to run at startup.

Further, M$ in their wisdom made .net unavailable in safe mode so a
whole bunch of utilities that might have helped investigate will not
work.

A good thing too! Utilities to run in basic configurations like safe
mode should not require complex support frameworks like dot-net has.
Moreover, a lot of malware now uses Powershell scripts (which need
dot-net) to initiate infection.

Mayayana wrote:

"Jeff Barnett" wrote

| Assume that a malicious code somehow enters your system. It simply puts
| itself on the "shutdown list" if there is such an entity. At shutdown it
| puts itself on the startup list(s). At next startup, it does what it
| wants then removes itself from the startup list(s) and adds itself to
| the shutdown list.

As far as I know there is no such thing. Something
that wants to run at reboot puts itself in the Run or
RunOnce key... or the startup folder... or whatever.

How can there be no such thing? Since users can define a logoff script,
and Task Scheduler, as I mentioned, can trigger on the shutdown event to
run a program, yep, what you can do so can malware. Logon/logoff
scripts, and Task Scheduler events that trigger on event IDs, are
outside the expertise of normal users. Maybe they even know about
SysInternals' AutoRuns, but they'd have to know about where are the
logon and logoff scripts, or understand how event IDs (and research what
causes them) can be used in Task Scheduler. There are also WinLogon
events defined in the registry (which AutoRuns will expose), but most
users don't know what WinLogon events can do, like installing a shell
extension when Windows reads through the registry to load those to
modify objects, like files and folders. Also, the Run[Once] keys are
loaded after Windows has reached a certain load point. A logoff or
shutdown event can modify Windows, so it is effective before Windows
even starts to load hence before when Startup Programs will load.

To me, malicious tricks in logoff or shutdown events can be used to
alter behavior on the next load of Windows instead of waiting when
Windows gets around to running the Startup programs.

The problem I see is the concern about logon/logoff scripts, however,
implemented, are looking the wrong way at the problem. For the scripts
to work (to run a program) means that the program had to first get
installed. If your anti-malware tool(s) don't detect the deposit of
malware files on your computer, they'll also be useless when the logon
or logoff script runs the infected file. Of course, scripts can make
changes in settings or policies that would become effective on the next
load of Windows, so they can fark over the use of Windows without ever
having loaded an executable program.

On 11/14/2020 1:15 PM, Apd wrote:
"Jeff Barnett" wrote:
Assume that a malicious code somehow enters your system. It simply puts
itself on the "shutdown list" if there is such an entity. At shutdown it
puts itself on the startup list(s). At next startup, it does what it
wants then removes itself from the startup list(s) and adds itself to
the shutdown list. Since we seem to have no way to examine the shutdown
list, this code remains hidden from sight. That is unless you know how
to use some utilities unknown to the vast majority of us.

I've never seen any use of a "shutdown list" by malware in my years of
dissecting samples. When malware first runs it may set itself to run
from the startup folder, autorun.ini or set one or more of the many
registry entries that specify programs to run at startup.

Further, M$ in their wisdom made .net unavailable in safe mode so a
whole bunch of utilities that might have helped investigate will not
work.

A good thing too! Utilities to run in basic configurations like safe
mode should not require complex support frameworks like dot-net has.
Moreover, a lot of malware now uses Powershell scripts (which need
dot-net) to initiate infection.

I think that you want to work on the wrong end of the problem. I believe
also that you don't want an enormous kludge such as .net in safe mode.
However, it is a disaster to build basic utilities needed for DEBUGGING
using .net so they are not available in safe mode when they are most needed.

PS I actually thought I was one down (in the windows 7 newsgroup). Not
sure if what I said is relevant in XP or not.
--
Jeff Barnett

"VanguardLH" wrote


| How can there be no such thing? Since users can define a logoff script,
| and Task Scheduler, as I mentioned, can trigger on the shutdown event to
| run a program

I mentioned task scheduler. As I said, all sorts of sneaky
things can be done, including adding services that most
people won't see. And there are lots of startup options.
But as far as I know there's no such thing as a run-at-shutdown
Registry key. And Autoruns lists no such thing.

Logoff scripts ... I'll take your word for it. I've never
logged off in my life. How do you set up a logoff script
to run at shutdown? In the Registry? I don't see anything
like that in Autoruns.

"Jeff Barnett" wrote:
On 11/14/2020 1:15 PM, Apd wrote:
"Jeff Barnett" wrote:
Further, M$ in their wisdom made .net unavailable in safe mode so a
whole bunch of utilities that might have helped investigate will not
work.

A good thing too! Utilities to run in basic configurations like safe
mode should not require complex support frameworks like dot-net has.
Moreover, a lot of malware now uses Powershell scripts (which need
dot-net) to initiate infection.

I think that you want to work on the wrong end of the problem.

How so?

I believe
also that you don't want an enormous kludge such as .net in safe mode.

That's another way of saying what I said!

However, it is a disaster to build basic utilities needed for DEBUGGING
using .net so they are not available in safe mode when they are most needed.

I agree.

Mayayana wrote:

"VanguardLH" wrote

| How can there be no such thing? Since users can define a logoff script,
| and Task Scheduler, as I mentioned, can trigger on the shutdown event to
| run a program

I mentioned task scheduler. As I said, all sorts of sneaky
things can be done, including adding services that most
people won't see. And there are lots of startup options.
But as far as I know there's no such thing as a run-at-shutdown
Registry key. And Autoruns lists no such thing.

Logoff scripts ... I'll take your word for it. I've never
logged off in my life. How do you set up a logoff script
to run at shutdown? In the Registry? I don't see anything
like that in Autoruns.

Since it is usually defined as a policy (for both logon and logoff
events), it is a registry entry. I don't have them defined, so there's
no way for me to tell if AutoRuns captures them, or under what category
or location it would list them. I also don't see AutoRuns listing the
shell extensions that get loaded when Windows reads the registry to
notice them. To me, programs that add themselves as shell extensions or
property sheets that get loaded from their registry definitions when
Windows starts up should also qualify as startup programs. Those get
loaded on Windows startup to affect behaviors or features. However, I
can see why AutoRuns doesn't include them, just like it doesn't list all
the policies (configured away from the install-time defaults) that can
also alter behaviors or features.

Guess AutoRuns relegates those policies, including logon/logoff
definitions, to the Group Policy Editor, but which Home editions users
won't have. There are lots of articles about how to get gpedit.msc into
Home editions of Windows; however, many have the user copying a
gpedit.msc file from elsewhere, and then adding some registry entries
(and twice for x64 versions). There's one I found that tries to get
gpedit.msc from the packages that have stored by the Windows
installation.

Articles:
https://www.majorgeeks.com/files/det...licy_plus.html
https://www.techspot.com/guides/1719...-windows-home/
https://www.ghacks.net/2017/07/25/po...dows-editions/
Github repository:
https://github.com/Fleex255/PolicyPlus

I did a search on .*GroupPolicy-ClientTools-Package~.*\.mum using regex
in [Search] Everthing, and found 102 locations with matching files. The
article focuses on a particular folder, I changed the search to
C:\\Windows\\servicing\\Packages\\.*GroupPolicy-ClientTools-Package~.*\.mum
which found 6 matching files. Since the for-loop is going to extract
from those files in the order found, it would get gpedit.msc from the
last one which has 10.0.19041.610 in its filename.

The article also mentions a 3rd party gpedit replacement: Policy Plus.
I've never used it, and didn't know about it until now. Since it is a
portable tool, I don't see how it can rely on any .NET frameworks, any
version. Because it can only edit the local policies, it seems more
more equivalent to secpol.msc (Local Security Policy Editor) than
gpedit.msc (Group Policy Editor).

I was wondering how it would keep up with changes to policy sets
(changes between Windows versions and feature updates). The Ghacks
article mentions you use the "Help - Acquire ADMX Files" menu.

https://docs.microsoft.com/en-us/tro...-central-store

I'd have to monitor network connections from Policy Plus to see just
where it retrieves the .amdx files. I remember finding Microsoft's
Excel spreadsheet on all the policies and their registry settings, but
my last attempt led to a dead end where the spreadsheet was described
but no download link to it.

Oh ****, just read this in the readme.md file at the Github site:

https://github.com/Fleex255/PolicyPl...ster/README.md
"Policy Plus requires .NET Framework 4.5 or newer. That can be
installed on Windows Vista or newer, and comes preinstalled on Windows
8 or newer."

Well, I suppose those libs have the function calls needed to do the
templates and registry edits although I would think all the tool would
really need is the .admx file(s).

That readme.md file also states:

"Some administrative templates are present by default on these
editions, but many are missing. The newest full package can be
downloaded from Microsoft and installed with Help | Acquire ADMX
Files."

Well, I'd monitor the program using TCPview to check it really only
connected to a Microsoft site. I'll leave shortcuts on my desktop to
look later at this possible gpedit.msc replacement. I'm a bit leery
about extracting multiple gpedit.msc files from multiple .mum package
files with each getting stepped on until the last .mum was found in the
for-loop. I might go the for-loop route since that gives me the
gpedit.msc from Microsoft, but that'll be after an image backup to give
me an escape to the prior state. Alas, the for-loop route looks like I
still have to copy from C:\Windows\SysWOW64 the gpedit.msc file and
GroupPolicy and GroupPolicyUsers folders into C:\Windows\system32.

Since AutoRuns doesn't list policies, you need a different tool to see
those, like for the logon/logoff policies.

Pyotr,

Keep us informed on any progress.

A major setback : the vbscript "run" command comes back with "WshShell.Run:
Unable to wait for process." when it runs something thru a shortcut (tested:
script and executable).

Even though I can wrap the command itself in an "on error", the caller not
waiting for the callee to finish could mean it gets aborted halfway. :-(

Regards,
Rudy Wieser

On Fri, 13 Nov 2020 14:34:11 +0100, R.Wieser wrote:

But do you know in which order the "logon" scrips and the contents of the
"startup" folder is executed - and if that makes any difference in, for
example, being able to access the current users data ? And if maybe
something else happens inbetween ? I don't.

And thats apart from the question under who's credentials the "logon" &
"logoff" scripts are run. Would not be nice when the "logoff" scripts would
be run by a process with other/more permissions as the user the generated
data is ment for ...

But ... that all would be moot (in my current case) if the OS supports
running the contents of a "shutdown" folder in the same way as it supports
the "startup" folder. Any idea ?

Regards,
Rudy Wieser

Logon/logoff scripts are run using the logged-on user account, and
Startup/shutdown scripts are run using the System account. In Vista+,
Logon/Logoff scripts may be run using a fixed predefined integrity level (I
haven't actually checked).

In both cases, the scripts are run within the Logon session (the logon
screen) instead of the interactive session (the work screen). So, none of
the scripts will be visible on the monitor.

During a system startup, Startup scripts are run before the Logon scripts.
And during system shutdown, Logoff scripts are run before Shutdown scripts.

JJ,

Logon/logoff scripts are run using the logged-on user account,

Thats sounds logical and therefore I already assumed as much.

and Startup/shutdown scripts are run using the System account.

Also logical, as there is no active user anymore. I will have to google
for "system account" to see what its drawbacks and benefits are.

In both cases, the scripts are run within the Logon session (the
logon screen) instead of the interactive session (the work screen).
So, none of the scripts will be visible on the monitor.

You know I'm going to test that, do you ? :-)

During a system startup, Startup scripts are run before the Logon
scripts.

Thanks. Thats one I must remember.

And during system shutdown, Logoff scripts are run before
Shutdown scripts.

:-) Its hard to log off when the 'puter itself has already shut down, so
thats logical too.

Regards,
Rudy Wieser

"VanguardLH" wrote

| I also don't see AutoRuns listing the
| shell extensions that get loaded when Windows reads the registry to
| notice them.

? I have them listed. I also see services listed. And
protocol handlers. Offhand I don't see anything missing.


| To me, programs that add themselves as shell extensions or
| property sheets that get loaded from their registry definitions when
| Windows starts up should also qualify as startup programs.

Yes. But of course, people are not supposed to be interested
in that. Even something put in the Startup folder as a shortcut
will never be known by most people. If not for Autoruns we'd
have no options but to check Run keys and hope for the best.

| Guess AutoRuns relegates those policies, including logon/logoff
| definitions, to the Group Policy Editor, but which Home editions users
| won't have.

My version of Autoruns is 9.57. I just tried the current version
and found even more things listed. But it's can't include everything.
Example: I wrote my own drop handler and Explorer bar. The
Explorer Bar must be loaded via BHO. Autoruns lists the BHO
and the drop handler, but it can't list the Explorer Bar because
Windows is not starting that.

GPE is pretty much just a front-end for IT people
who don't know how to use the Registry. I've rarely used it.
Mostly I only use it when I find a setting I want and the dim
bulb who posted it online only posted the GPE setting, not
realizing it was actually a Registry setting.

| Oh ****, just read this in the readme.md file at the Github site:
|
| https://github.com/Fleex255/PolicyPl...ster/README.md
| "Policy Plus requires .NET Framework 4.5 or newer. That can be
| installed on Windows Vista or newer, and comes preinstalled on Windows
| 8 or newer."
|
| Well, I suppose those libs have the function calls needed to do the
| templates and registry edits

People use .Net because they don't know how to do
such things or can't be bothered. Registry editing is all in
advapi32.dll. It's part of the original, base library set. I
don't know of anything that .Net is *needed* for. It's
just a superfluous API wrapper. But it does, of course,
make a lot of things easier.

Mayayana wrote:

"VanguardLH" wrote

| I also don't see AutoRuns listing the
| shell extensions that get loaded when Windows reads the registry to
| notice them.

? I have them listed. I also see services listed. And
protocol handlers. Offhand I don't see anything missing.

I had expected a tab named for those. Under the Everything tab, and
after scrolling around for a bit, I found the shell extensions listed.
So, I wandered around the tabs looking for them, and found them under
the Explorer tab. One of those "DOH!" moments.

"R.Wieser" on Sun, 15 Nov 2020 10:59:14 +0100
typed in microsoft.public.windowsxp.general the following:
JJ,

Logon/logoff scripts are run using the logged-on user account,

Thats sounds logical and therefore I already assumed as much.

"That sounds logical. Which means it probably is not the way the
MicroSoft would do it."
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

Pyotr,

Thats sounds logical and therefore I already assumed as much.

"That sounds logical. Which means it probably is not the way
the MicroSoft would do it."

:-) You got me there I'm afraid. And I even have my examples of how MS can
do ... stupid things.

Regards,
Rudy Wieser

P.s.
I've "fixed" the "Unable to wait for process" problem : In the case of a
shortcut I'm using "CreateShortcut" to extract the target (and argument),
after which I "run" the result.

On Sun, 15 Nov 2020 10:59:14 +0100, R.Wieser wrote:

You know I'm going to test that, do you ? :-)

Be my guest.

:-) Its hard to log off when the 'puter itself has already shut down, so
thats logical too.

Keep in mind that Shutdown is not same as Log-off, or vice versa. A log off
process doesn't necessarily shuts down the system. And not everyone only has
one user account in their computer.

So, one can log off (thus triggers the Logoff scripts) to log in using a
different account (thus triggers the Logon scripts). Without triggering any
of the Shutdown scripts.

Or... use the Fast User Switching to logon another user. Thus triggers the
Logon scripts without triggering Logoff script for any user. Logoff scripts
will be triggered only when a user actually logs off.

JJ,

Keep in mind that Shutdown is not same as Log-off, or vice versa.

I know. I've been fighting with myself about what I should name the new
directory : "shutdown" or "OnLogoff". The first matches the "startup" one
better*, the second is /way/ closer to the truth.

*if you have a good, opposite name to "startup" than please do mention it.

In my case its a bit moot though as I never logoff but /always/ power the
machine down.

Or... use the Fast User Switching to logon another user. Thus triggers
the Logon scripts without triggering Logoff script for any user. Logoff
scripts will be triggered only when a user actually logs off.

Argh.... I didn't even think about that.

Regards,
Rudy Wieser