
Windows NTFS Tricks Collection - conductor
https://sec-consult.com/en/blog/2018/06/pentesters-windows-ntfs-tricks-collection/
======
mehrdadn
> Another interesting fact is that ADS names can contain symbols which are
> normally forbidden for filenames like ” or *

OK, this is going to _completely_ mess up all of my (and most likely everyone
else's) shell scripts. I always assume these characters cannot legally occur
on Windows anywhere in the path...

_________________________________________

And wow, this is quite clever and also quite difficult to foresee:

> The best security vulnerability to explain directory junctions is in my
> opinion AVGater, where the attacker places a file in folder x. Then he marks
> the file as a virus and the installed AntiVirus solution will move it into
> the quarantine. After that the attacker removes the folder x and replaces it
> with a directory junction named “x” which points to C:\windows\System32\\.
> If the attacker now clicks on the “restore” button the AntiVirus solution
> will copy the file to the x folder which now points to system32 with SYSTEM
> privileges (which directly leads to EoP).

~~~
quietbritishjim
For that second one: That sounds like a vulnerability in virus scanners even
without junctions, although junctions make it enormously easier to exploit:

* Create a directory in a location you have permission to, but you think a higher-privilege user will create it later.

* Create and quarantine a file in it.

* Delete the directory.

* When the higher privilege user creates the directory, you can restore your file into it.

The fix is for virus scanners to operate at user permission level when
restoring the file.

~~~
AnIdiotOnTheNet
Ok, let me ask: why? What is the absolute worst case scenario here? That a
user in your organization gains admin privileges on their workstation?

Nearly every org I've ever worked at already gave their users admin privileges
because trying to do their job without it caused far more friction than any
imaginary gains from locking them down. So they might screw up their OS, big
deal, that's what imaging is for.

It's not like ransomware needs admin privileges to ruin your day anyway. In
fact, local admin does absolutely nothing for it since it will still only have
permissions to the same network resources that the user does, and of course
their local documents.

There are some kiosk-style single-application appliance use cases out there
where it makes sense to lock things down just to make sure the user isn't
browsing reddit all day or something, but by their nature those are at low
risk of being infected and you care even less about them than a workstation if
they are.

I honestly can't think of a realistic scenario in which this isn't a complete
non-issue.

~~~
grkvlt
> Nearly every org I've ever worked at already gave their users admin
> privileges

I assume you've never worked at a large retail or investment bank, or similar
organisation, then? Admin privileges are _never_ granted to ordinary users; to
install new programs or perform administrative tasks requires a call to the
helpdesk, and there is usually some form of remote management service running
to handle updates and so on.

~~~
AnIdiotOnTheNet
Ok, but why? What does that actually accomplish?

~~~
KAMSPioneer
Just a few ideas off the top of my head:

An attacker that gains SYSTEM permissions on a machine can dump the SAM
database, which may contain credentials for domain or enterprise
administrators. This is very bad.

A user with administrator permissions can modify their DNS settings to avoid
DNS-level filtering to block known malware domains. This can be bad.

A malicious or ignorant user can disable or remove antivirus protection. This
can be bad.

A user can accidentally make a computer nonfunctional by, for example,
deleting system files, perhaps because it was suggested (sarcastically) on a
help forum ("LOL delete system32"). This is bad.

I'm far from a security expert, but from a sysadmin perspective, every user
having local admin privs is an absolute nightmare.

~~~
AnIdiotOnTheNet
> An attacker that gains SYSTEM permissions on a machine can dump the SAM
> database, which may contain credentials for domain or enterprise
> administrators. This is very bad.

True enough, but unlikely to be a significant risk. If you are concerned about
it then it is much easier to have a separate AD account that only has local
administrator on normal (non-admin) workstations and use that.

> A user with administrator permissions can modify their DNS settings to avoid
> DNS-level filtering to block known malware domains. This can be bad.

It is trivial to block or even reroute DNS queries to unapproved servers at
the firewall. At least until DNS over HTTPS ruins that and simultaneously
renders your point moot.

> A malicious or ignorant user can disable or remove antivirus protection.
> This can be bad.

I disagree. Anti-virus software has negative value and always causes
significantly more trouble than it is worth. Case in point, the very issue
we're talking about.

> A user can accidentally make a computer nonfunctional by, for example,
> deleting system files, perhaps because it was suggested (sarcastically) on a
> help forum ("LOL delete system32"). This is bad.

This is a minor inconvenience at best, that's what imaging is for.

> I'm far from a security expert, but from a sysadmin perspective, every user
> having local admin privs is an absolute nightmare.

If it were a nightmare, I'd have expected to see more issues arise from it
throughout my career, but I've yet to see even one instance where a user
having local admin has caused any significant trouble.

~~~
KAMSPioneer
> True enough, but unlikely to be a significant risk. If you are concerned
> about it then it is much easier to have a separate AD account that only has
> local administrator on normal (non-admin) workstations and use that.

I strongly disagree. If an attacker gains access to a system as an admin user,
that is a much larger problem than a non-admin user. Designing an environment
as you suggested helps compartmentalize that, but it doesn't help the fact
that a SAM database from one of those machines can potentially spell an almost
company-wide compromise. Such a strategy gives far too much opportunity for
lateral movement in case of a single compromised machine.

> It is trivial to block or even reroute DNS queries to unapproved servers at
> the firewall.

That's a good point.

>I disagree. Anti-virus software has negative value and always causes
significantly more trouble than it is worth. Case in point, the very issue
we're talking about.

Regardless of your feelings on antivirus (I'm ambivalent myself), I don't
quite see how a potential abuse of an antivirus software, which can lead to
EoP, is justification for allowing all users in an enterprise to have full
local admin privileges. You're cutting out the step where an attacker has to
exploit an EoP vulnerability.

> This is a minor inconvenience at best, that's what imaging is for.

True, but if I can avoid the trouble by limiting user privileges, why not?

> If it were a nightmare, I'd have expected to see more issues arise from it
> throughout my career, but I've yet to see even one instance where a user
> having local admin has caused any significant trouble.

It's possible it may never be a problem in $arbitraryEnvironment, but that
doesn't make it good security practices. I can imagine that in smaller
environments, it may even be somewhat manageable.

There will probably be circumstances that create a need for local admin access
as you described, but I don't think it should be the modus operandi.

~~~
AnIdiotOnTheNet
> I strongly disagree. If an attacker gains access to a system as an admin
> user, that is a much larger problem than a non-admin user.

Not really. There's quite a lot you can do as a non-admin user too you know.
You can probe anything on the internal network that machine has access to and
act as a relay for the attacker, for instance. Since the user does work for
the company, they probably already have access to a lot of things the
organization would rather not give out. Local admin gives you a few more
options, but the difference isn't really worth special attention in my book.

> True, but if I can avoid the trouble by limiting user privileges, why not?

Because you're also causing a lot of friction for the users. Users do work too
you know, in aggregate hopefully a lot more than sysadmins. Every barrier you
put between them and their work is a cost, and my argument is that the cost of
locking everyone out of local admin pretty much always outweighs the benefits.

> I don't quite see how a potential abuse of an antivirus software, which can
> lead to EoP, is justification for allowing all users in an enterprise to
> have full local admin privileges.

It isn't, it's justification for disregarding "could disable the virus
scanner" as a valid reason for denying local admin to the user.

"Good security practice" is often, in my experience, either a lot of academic
crap that completely ignores the concept of risk analysis, or what someone
who's trying to sell you something recommends. Every barrier you put between
people and their ability to do work for the company is a cost that you have to
justify against the cost of a compromise _and_ the probability of said
compromise actually occurring.

Depending on your environment, that level of cost may be worth it, but I think
that's true for a much smaller segment than a lot of people who argue the
point. I suspect this is because my paycheck depends on keeping the business
running smoothly, not selling security consulting services.

~~~
KAMSPioneer
> Not really. There's quite a lot you can do as a non-admin user too you know.

Yeah, of course. Otherwise ransomware would be much less prevalent than it is
today. That said, there's quite a bit an admin user can do that a normal one
cannot. I suppose we just disagree on how important the distinction is.

> Local admin gives you a few more options, but the difference isn't really
> worth special attention in my book.

And that's fine, but surely you can see why plenty of organizations feel that
it is, right?

> Because you're also causing a lot of friction for the users...Every barrier
> you put between them and their work is a cost, and my argument is that the
> cost of locking everyone out of local admin pretty much always outweighs the
> benefits.

Well I can only speak to my experiences, but given the technical knowledge of
90% users on systems I support...it is definitely worth the cost.

> It isn't, it's justification for disregarding "could disable the virus
> scanner" as a valid reason for denying local admin to the user.

Touché. That said, in environments with antivirus requirements, for whatever
reason, a user being able to remove such a program is a problem.

> "Good security practice" is often, in my experience, either a lot of
> academic crap that completely ignores the concept of risk analysis, or what
> someone who's trying to sell you something recommends.

The same could be said RE: antivirus. In many situations, protecting a user
from running dangerous applications (e.g. a trojan delivered by a social
engineering attack) is likely more important than a hypothetical escalation of
privilege by a user who calls helpdesk every time their password expires.

> Depending on your environment, that level of cost may be worth it, but I
> think that's true for a much smaller segment than a lot of people who argue
> the point. I suspect this is because my paycheck depends on keeping the
> business running smoothly, not selling security consulting services.

Hey, it sounds like we're in the same business! :) I agree, different
environments = different requirements. But that doesn't make for good
headlines, either.

~~~
AnIdiotOnTheNet
> Well I can only speak to my experiences, but given the technical knowledge
> of 90% users on systems I support...it is definitely worth the cost.

Is this meant to mean they have high or low technical knowledge? Because we
support some users with a decidedly low understanding of... well, everything
really, and it hasn't been a problem. They still give help desk a lot of
grief, but it's because they don't know that windows can be minimized and
things like that. Accidentally installing malicious applications or other
reasons you'd think of restricting them really just doesn't come up.

~~~
KAMSPioneer
Well, there are two groups that worry me: those that don't know Windows can be
minimized, and those who believe they're much better at using computers than
they actually are. And honestly, the second group worries me more.

That group doesn't represent the majority of users by any means, of course.

~~~
AnIdiotOnTheNet
Yeah, that makes sense. If I had to deal with a lot of that then workstation
restrictions would probably be a lot more appealing.

------
0x9000beaf
how about using the original website of the researcher who identified all of
this and not just a cheap copy?

[https://www.sec-consult.com/en/blog/2018/06/pentesters-
windo...](https://www.sec-consult.com/en/blog/2018/06/pentesters-windows-ntfs-
tricks-collection/)

------
nkkollaw
When I used Windows, I remember you couldn't create folders named "con", for
compatibility reasons.

It kind of sucked because it means "with" in Italian, and I often could have
organized files within "with"/"without"subfolders.

~~~
kingaillas
That's just one of the many reserved file/device names in Windows!

"Do not use the following reserved names for the name of a file: CON, PRN,
AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2,
LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9." [0]

[0] [https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa365247\(v=vs.85\).aspx)

~~~
cesarb
Note, they are not just reserved names, they are reserved names _with any
extension_.

So when a Unix user checks in a file named "aux.c" to your project, it will
cause problems for Windows users.

------
voltagex_
Site is down,
[http://web.archive.org/web/20180613213214/https://movaxbx.ru...](http://web.archive.org/web/20180613213214/https://movaxbx.ru/2018/06/13/windows-
ntfs-tricks-collection/) should be an archive but I can't check from my
current location

~~~
rbanffy
[https://webcache.googleusercontent.com/search?q=cache:4L1CWH...](https://webcache.googleusercontent.com/search?q=cache:4L1CWH8fqqQJ:https://movaxbx.ru/2018/06/13/windows-
ntfs-tricks-collection/+&cd=1&hl=en&ct=clnk&gl=ie) seems OK

------
zokier
Are ADS used for anything useful anywhere? It is kinda interesting how long MS
has been carrying that feature around, especially as it is not really highly
advertised feature; is it really even supported? ADS does constantly pop up in
these sorts of (semi-)malicious contexts, simply dropping them seems like
sensible thing.

~~~
mehrdadn
The current uses in Windows I'm aware of (not including external programs)
are:

\- :$I30, :$Bad, $Info, $SDH, and a number of others, internally used to name
the stream that stores the children of directories. But the stream names seem
pretty unnecessary to me; they aren't exposed to external code so they could
well be different files and it wouldn't affect any user.

\- :Zone.Identifier, for denoting whether a file is from an untrusted origin
(so you can get that annoying pop-up every time you run a downloaded file)

\- :WofCompressedData, for the newer transparent file compression mechanism
(older ones were different)

\- :Win32App_1, used for I'm-not-sure-what

\- :encryptable, used along with Thumbs.db, also for I'm-not-sure-what

\- I think there was one more regarding extended properties or something, but
I can't think of it right now.

Aside from breaking :WofCompressedData I don't think anyone outside Microsoft
would shed any tears if it was removed.

~~~
voltagex_
How are the current placeholders for OneDrive implemented?

~~~
hug
Doesn't look like it's via ADS -- synced items on my desktop have only the
single stream.

Except for one item I just created to test that has a stream called "magic".

~~~
voltagex_
Seems like it's done via a filesystem filter driver - calls to open files from
OneDrive-unaware applications block until the file is downloaded.

~~~
mehrdadn
That's a different problem though, right? I thought you were asking where
OneDrive stores the information necessary to know where the file is located on
your cloud storage, and it would make sense for that to be in a stream.

~~~
sebazzz
Yes, but the stream will remain if copied to another NTFS volume. That may
cause issues.

~~~
mehrdadn
What kinds of issues?

~~~
sebazzz
If you copy indirectly from OneDrive folder to another OneDrive folder, the
file may not sync due to the ADS indicating that the data is already uploaded.

------
strkek
Last time I checked you could create a directory with a name "like:this" from
Linux or something, and Windows would display it but not allow you to access
it in any way.

Have they fixed this? (Just pure curiosity)

~~~
j4_james
Interestingly, when you create a file name from the WSL shell using reserved
Windows characters, those characters will get mapped to unicode codepoints
from the private use area when viewed in Windows. So for example a colon
(\u003A) will show up in Windows as \uF03A.

This means you can create a filename in Windows using the character \uF03A,
and that character will show up in the WSL shell as a colon. You can even do
the same thing with "regular" characters, e.g. using \uF061 instead of "a",
and produce a filename that appears to be ASCII in the WSL shell, but is not
actually accessible.

~~~
lloeki
Mac OS X maps filenames between slash `/` and colon `:` to match with UFS, the
colon used to be the path separator on old MacOS, which HFS+ inherited.

Try it:

    
    
        $ touch foo:bar
        $ open .
        # Look at the filename in Finder.
        # Try it the other way around by saving a file
        # with / in TextEdit, then ls in Terminal.
    

[0]: [https://stackoverflow.com/questions/13298434/colon-
appears-a...](https://stackoverflow.com/questions/13298434/colon-appears-as-
forward-slash-when-creating-file-name#13298479)

------
dc_gregory
If you created some directories to test, you can delete them with bash
(whatever git installs works). It does create nested directories, so you need
to do:

    
    
        rmdir .../.../
        rmdir .../

~~~
ocdtrekkie
Speaking of, my favorite stupid Windows trick I discovered, was before long
file support, you could get nested folders too long for Windows to handle due
to some cool bugs and couldn't delete them with rmdir.

But I discovered I could robocopy sync a blank folder over them, and it was
more than happy to oblige. robocopy is seemingly a more robust deletion tool
than rmdir.

~~~
ygra
rd might work when prefixing the path explicitly with \\\?\; robocopy likely
already uses that syntax internally to deal with long paths.

------
beefhash
Another fun thing you can do with NTFS transactions: process doppelgänging;
see [https://hshrzd.wordpress.com/2017/12/18/process-
doppelgangin...](https://hshrzd.wordpress.com/2017/12/18/process-
doppelganging-a-new-way-to-impersonate-a-process/)

------
jaclaz
Similar to the ... (Trick 3) here is some fun with ALT+0160:

[https://msfn.org/board/topic/131103-win_nt~bt-can-be-
omitted...](https://msfn.org/board/topic/131103-win_nt~bt-can-be-
omitted/?do=findComment&comment=842843)

------
leibnitz27
I wrote a shell extension some time ago to make playing with ADS easier :
[http://www.benf.org/other/alternatestreamoverlay/index.html](http://www.benf.org/other/alternatestreamoverlay/index.html)

------
gcbw2
wonder if the "...\\...\" trick can be used to overflow the counter of files
to delete and execute arbitrary data as the system user.

------
SecABC
The original blog can be found here: [https://sec-
consult.com/en/blog/2018/06/pentesters-windows-n...](https://sec-
consult.com/en/blog/2018/06/pentesters-windows-ntfs-tricks-collection/)

The author of the above blog copy & pasted the full article, explicitly
removed the author names and references to the original source. That's pretty
disappointing.

~~~
landave
Wow. It appears that movaxbx.ru copied multiple of my blog posts as
well[1][2][3][4].

I wonder how hard it would be to take legal action (in particular to stop them
from doing this altogether, as opposed to just taking down a single article).
The site appears to be hosted in Russia[5]. From a quick glance over the
Wikipedia page[6], it seems to me that Russian copyright law is quite similar
to copyright law in most developed countries.

[1]: [https://movaxbx.**/2018/06/05/f-secure-anti-virus-remote-
cod...](https://movaxbx.**/2018/06/05/f-secure-anti-virus-remote-code-
execution-via-solid-rar-unpacking/)

[2]: [https://movaxbx.**/2018/05/04/7-zip-from-uninitialized-
memor...](https://movaxbx.**/2018/05/04/7-zip-from-uninitialized-memory-to-
remote-code-execution/)

[3]: [https://movaxbx.**/2018/05/04/7-zip-multiple-memory-
corrupti...](https://movaxbx.**/2018/05/04/7-zip-multiple-memory-corruptions-
via-rar-and-zip/)

[4]: [https://movaxbx.**/2018/05/04/bitdefender-heap-buffer-
overfl...](https://movaxbx.**/2018/05/04/bitdefender-heap-buffer-overflow-
via-7z-lzma/)

[5]: [http://ip-api.com/#movaxbx.ru](http://ip-api.com/#movaxbx.ru)

[6]:
[https://en.wikipedia.org/wiki/Copyright_law_of_Russia](https://en.wikipedia.org/wiki/Copyright_law_of_Russia)

------
txdv
Those tricks look like exploits to me. O, russian domain xD

~~~
rbanffy
Assuming bad intentions from nationality is kind of racist. I get the tricks
(and the examples given) seem to be usable maliciously, but we need to know
the threats so we can protect against them.

~~~
MaxBarraclough
That's not what 'racist' means.

~~~
pbhjpbhj
It's within some dictionary definitions of racist; but xenophobia is barely
better. Most people don't have control over their nationality.

