Viewing file activity on a Remote fileshare without permissions

At Ignite 2019 in Orlando I demonstrated how you can view file activity on a remote share with no permissions. This demo is made against a "Home folder share" which normally allows only very limited rights to the shares root, and then NO PERMISSIONS for anything under it. By Microsoft's opinion this is not a problem and not a security issue because I can't see the content of the files but only the file names. I don't agree at all as the file names, and all metadata what so ever, are in my opinion "data" as well. The weakness is deep inside the filesystem and you can abuse it with different languages. I will use PowerShell.

Does this mean that I can read other peoples email as long as I only read the Subject?

What you need is very simple. Start by downloading this PS Module from this article here: https://mcpmag.com/articles/2015/09/24/changes-to-a-folder-using-powershell.aspx

Then load the module, and allow it to run - depending on your environment you might need Set-Executionpolicy first.

Run Start-FileSystemWatcher -Path "\\server\yourhomeshare" -Recurse

Now you can see all file activity, even if you don't have permissions to do so ;)

Cheers from Orlando,

Sami

PS. A lot of credit on helping me to find this has to go to Mr. "T" from Finland.

TechMentor 2018 Redmond - Better price with my chairmans code!

I’ll be speaking at TechMentor, August 6-10 at Microsoft HQ in Redmond. Surrounded by your fellow IT professionals, TechMentor provides you with in-depth, immediately usable training that will keep you relevant in the workforce.

I’ll be presenting the following sessions:

• M01 - Workshop: How to Prevent all Ransomware / Malware in 2018
• W02 - Troubleshooting Sysinternals Tools 2018 Edition
• W10 - Deploying Application Whitelisting on Windows Pro or Enterprise

SPECIAL OFFER: As a speaker/chair, I can extend $500 savings on the 5-day package. Register here: http://bit.ly/RDSPK12_reg

Stored passwords found all over the place after installing Windows in company networks :(

Hi everyone!

It's been a while as I had a nice summer and a busy Techmentor conference after my holiday, and hence I haven't really had the chance to blog :/

Now many of you have seen me point out how hacking into company computers is many times a lot easier than banging on every door with Kali Linux and an armada of different exploits. I'm what I call a conceptual hacker more that a shooting hacker. I like to use deep knowledge of the OS for my benefit and try to find weaknesses based on that. And... I also luckily know a lot of smart people and networking is your core skill for all matters IT.

When I start to look into an environment one of the first things is to PXE boot a machine and hunt for MDT etc. that store passwords in all the wrong places. Now MS has gotten better on this and you know that they remove those quite well... I'll take that back... Not that well it seems.

A good friend of mine and a fellow MVP, Mikko Järvinen (@mikko_jarvinen) sent me a great summary of so many passwords stored in so many wrong places :) Most installation systems should use an account that is just a limited account with delegated privileges to join computers to a domain etc. BUT... We've all seen it, many just put in the Domain Admin accounts and passwords.

Here is Mikko's quote:

I discovered that username, domain and password of the user account used in installation of Windows from Windows Deployment Server will be left on the disk after Windows installation is finished and are readable by any user.

In Windows PE phase, Windows Setup creates a file "setupinfo" in "X:\Windows\Panther" (X: is the WinPE RAM disk). The username, password and domain of the user account which has authenticated to the Windows Setup (WDS mode) will be written in to this file in a readable format immediately after authentication. The information can be easily found by searching the following strings inside "setupinfo":

C r e d U s e r
C r e d D o m a i n
C r e d P a s s w o r d

After Windows installation has restarted from Windows PE to the Windows itself there is a new "setupinfo" file in "%systemroot%\Panther" folder, but there is also the original WinPE-phase "setupinfo" file which has been renamed to "setupinfo.bak". It is fully accessible and still contains username, domain and password information.

We know that MS cleans things like Unattend.xml to say *SENSITIVE*DATA*DELETED* so why don't they just do this all the way and clear these out as well... :(

There's a fix for this: just add a deletion of that file in the setupcomplete.cmd for example and for previously installed machines you could just add a GPP like Mkko shows here:

This was for WDS but many use MDT instead and just the WDS engine to PXE boot. Mikko also asked to remind about something that I've used as well. The fact that also MDT saves the credentials in the C:\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT. although not in clear text but Base64-encoded. Well that's sadly easy to decode so the if you lose that file the password is then bye-bye-captured-by-enemy.

These were all reported to Microsoft but as they require physical access Microsoft doesn't really bother to fix them as these anyway break the immutable laws of security. The truth in the end of the day still is that in many networks these allow an easy to achieve privilege elevation attack so I would strongly encourage you to make sure you are not affected and that that the user accounts used in installation don't have more than bare minimum privileges.

Cheers,

Sami

Is Group Policy Gonna Die? Do I have to use MDM in the Future? Interview with Jeremy Moskowitz

Hi everyone!

I believe most of my followers are wondering if Group Policy is going to be replaced By MDM or not. I am too and I have my own opinions on this which I am not afraid to share. In my last newsletter (link) I touched this topic a bit. I was honored to have Mr. Group Policy - Jeremy Moskowitz - himself contacting me and giving me his opinions on this. As he must know this better than most on this planet I asked him if he would do an interview on this topic. Oh boy was I happy when he said "Yes!"

Full Disclosure: Jeremy Moskowitz is a personal friend of mine, a 14-year Group Policy MVP and heck of an awesome guy. He teaches THE WORLD’S BEST Group Policy training (with MDM tips and tricks too!). He also runs PolicyPak software, which plugs into Group Policy/SCCM/MDM while doing amazing things. And because there is no way to shy away from it, I gave him permission to mention PolicyPak in this interview.

If you’re interested in his training and/or some insanely great Windows 10 management software, check out www.GPanswers.com and www.PolicyPak.com.

Now, on with the interview . . .

Q: What is MDM, and how is it different than traditional in-the-box management (Group Policy and SCCM)?

A: MDM stands for Mobile Device Management. It’s a new built-in agent-like “receiver,” similar to other agent-like “receivers” in Windows such as Group Policy, PowerShell, and RemoteRM, not to mention other “receivers” you might add on after the fact—SCCM, Altiris, or a zillion others.

MDM support actually started with Windows 8.1 but really wasn’t “ready” until Windows 10.

MDM requires a third-party server to be available to give MDM directives (policies) to endpoints; this occurs over XML using a thing called the “OMA-DM protocol.” The most popular MDM servers are Windows Intune, VMware Airwatch, and MobileIron. Plus, there are dozens more.
What’s special about MDM is that the protocol and “receiver” can work across a multitude of devices like iPhones, Androids, and Windows 10.

So the dream is “make one policy and apply it everywhere.” Then boom, you’re done!

It’s a nice dream, but it still has a ways to go.

Q: How do you feel about MDM in general?

A: I’m glad you asked that question. Sometimes people secretly ask me, “Hey, Jeremy, as one of the Group Policy MVPs, do you secretly hate MDM?” I tell them, “No, I don’t hate MDM; it’s not ‘hate-able.’”  In fact, MDM does a reasonable job in one key scenario: enabling users to bring or choose their own device when the IT admin doesn’t care how the machine ends up configured.

Actually, this is not only my opinion, but also Microsoft's official opinion. They've articulated MDM's strengths in this (recently updated) article about their modern management thinking:

https://technet.microsoft.com/itpro/windows/manage/manage-windows-10-in-your-organization-modern-management

Microsoft calls the new MDM way “modern management.” Who knows, maybe you’ll decide to trade in Group Policy for MDM to be more modern.

That sounds pretty cool, but, okay, here’s my analogy.

Let’s say you want to save money and trade in your old gasoline car (Group Policy) for a more efficient scooter (MDM). Great! On the plus side, you’ll have less payment of overhead (scooter insurance vs. car insurance), and there’ll be less to go wrong (a scooter is far simpler than a car.)

But after you do your trade-in, there are tradeoffs. As such, with your scooter, you’re not allowed to complain about not having enough horsepower or getting caught in the rain with no protection.

Remember, the scooter ISN’T meant to have a lot of horsepower or keep you out of the rain. The car is. On the other hand, the car isn’t meant to be a nimble, lightweight machine to navigate twisty sidewalks. The scooter is.  Oh, and neither a scooter (MDM) nor a car (Group Policy) is meant to do complex tasks or take you to the battlefield like a tank (SCCM) would.  These are simply different tools for different scenarios.

So if you trade in your car or tank for a scooter, you will likely save money. But there is a hidden cost: you (the admin) cannot care how the machine is configured or managed. In the MDM world, we call this “intent.” That is, you have to give up knowing what is happening end to end from a configuration perspective. Yes, there is some logging when MDM settings are actually applied, but it’s not a slam dunk to configure or troubleshoot.

As a company, and as an IT team, you have to decide if you want your Windows unmanaged (nothing at all), lightly managed (with MDM), managed (with Group Policy), and/or fully managed (with SCCM and/or SCCM alternatives). Each has pros and cons with different costs as well as security implications and pitfalls.

And, for the record, I own two cars and one scooter. (And zero tanks.)

Q: How do you see the future when it comes to GP vs MDM? On servers or clients?

A: I think you can think of Group Policy and MDM as you would IPv4 and IPv6.

Some people will have an immediate need for the new thing. Others will have no need at all. And others will have some mixed need. If clients are domain joined, Group Policy is going to be able to manage them. On this matter, Microsoft has been pretty clear: if they enable a new setting (say for Microsoft Edge or a security setting), Microsoft will encourage the team in charge of the setting to light it for use with the Group Policy channel and the MDM channel at the same time. Sometimes (and usually), the teams will do it correctly. Sometimes, there is some lag. I know, Sami, that you found an interesting setting that would fix a security hole, and the fix was ONLY MDM enabled. But with Windows 10, 1703 edition, they did what they said they were going to do, and they backported that setting to Group Policy.

So to me, Microsoft is basically keeping their promise: when they make a new setting, they Will Group Policy-enable and MDM-enable those new settings. It’s a good strategy, and it is one I really agree with.

Servers will either be domain joined or they won’t be. And they can either be “traditional” servers or Nano server. Nano has no Group Policy support. (See my take on this below.) For traditional servers, Group Policy will continue to work as expected if you want them to, or you can leverage DSC. (This is also explained below.)

Q: Is Microsoft going to give up on Group Policy?

A: I think this is the key question on people’s mind, and I have a pretty direct answer: Microsoft is not giving up on (also known as deprecating) Group Policy. They simply aren’t.
In order for Microsoft to give up on Group Policy, Microsoft has to first give up on the idea of on-prem domain controllers AND the idea of domain-joined machines—not just one idea but both.

When there are no more on-prem domain controllers, and IT admins start to say, “I won’t domain join a machine again!” only then can Microsoft think about giving up on Group Policy.

But don’t take it from me. Take it from Jeffrey Snover, who is a technical fellow at Microsoft and the person largely in charge of Windows as you know it. Here’s one of his tweets I suggest reading: https://twitter.com/jsnover/status/730104387591274496

With that being said, Group Policy for Nano is a different story when there is no Group Policy support. To address this issue, we refer to this tweet https://twitter.com/jsnover/status/730008240361103360, where Jeffrey Snover explains that on servers (especially Nano server) DSC is the replacement for Group Policy.

I do have one quibble with the current Group Policy world as it sits though. While the core is stable and not changing much except for bug fixes and minor updates, there are some areas in Group Policy Preferences that worked perfectly in Windows 7, but when Windows 8.1 (and later) came around, boom!, they stopped working. We call this a “breaking change.” The key areas that broke were Group Policy Preferences File Associations and Group Policy Preferences Start Menu settings. I’ll mention how these breaking changes can be worked around a bit later.

Q: How do you feel about Nano server not having the ability to get Group Policy directives at all?

A: After some deep soul searching—about five minutes—I agreed this was totally the correct decision. Nano doesn't need the Group Policy engine, and Group Policy isn’t the best for Nano.
On the one hand, you could argue, “If we could use Group Policy everywhere, we (IT admins) would only need to learn one thing, and it would work everywhere!”

Yep, that’s true. But it cannot be that way.

But in the same way there are different programming languages for different types of workloads (VisualBasic vs C++), there must be different management technologies for the right job (Group Policy vs. DSC).

For those who aren’t familiar with DSC, it stands for Desired State Configuration and is a toolkit built upon PowerShell to bring new servers (yes, only servers!) into the world very quickly to a desired end-all configuration. DSC does an amazing job at what it's meant to do: bring up 1 or 1000 servers and keep them configured.

Group Policy isn't trying to do that. It is the best way to manage and provide the end-user experience (look and feel settings, drive maps, shortcuts, and user-based restrictions to control panel, etc.) and client-computer security configuration.

That being said, if you have existing Group Policy settings, you’ll want to convert into DSCland, where Microsoft has some Powershell converter tools. But again, for 100000% clarity, supporting DSC on clients SHOULD NOT be attempted. DSC is for servers, servers and only servers.

Q: In your opinion, what are the biggest benefits and drawbacks when it comes to MDM?

A: On the plus side, MDM is interesting because it's the same protocol (OMA-DM) across operating systems as in Windows, devices such as Apple and Android, or whatever comes next (wireless brain-implants?!). This is similar to what Microsoft says about MDM, “It's great for devices that are constantly on the go,”(e.g., phones and tablety things).
But on the flipside, when you say, in MDM, "Force password policy to be strong," it could have different interpretations on the final device.

It's up to the MDM vendor to bring clarity to each setting and demonstrate on what device it's going to apply as well as what the ultimate experience is going to be.

Since MDM implementation is up to each vendor, there are a variety of items that you might or might not get, such as change management, reporting, backup/restore/rollback, inventory, reporting, and other things you, your IT team, and managers have come accustomed to.

By design, MDM isn’t trying to do EVERYTHING that Group Policy is trying to do. This can lead to a disconnect when people try an MDM pilot, where they will find that the things they are trying to do aren’t possible in MDMland.

In fact, people often ask us about PolicyPak Cloud AFTER a failed MDM pilot attempt because PolicyPak Cloud can literally deliver ALL of Group Policy TODAY over the Internet the way IT admin expect it to— which is expressly NOT a goal of MDM.

Q: I know PolicyPak On-Prem and PolicyPak Cloud add to what is “in the box” with Group Policy. Have you seen a change in what people ask for because of Windows 10?

A: First, thanks for the questions about PolicyPak. Here’s your beer. J

For people who don’t know what PolicyPak is, we’re an add-on for Windows 7, 8.1, and 10, which improves on the management of applications, browsers, Java, and operating systems. In other words, think new Group Policy Preferences items but for 21^st century needs. We have seven components and a zillion demos on our website.

First thing’s first, PolicyPak’s policies are agnostic. That is, we work with what IT admins are already using. You can deliver PolicyPak directives using

-          Group Policy (which is typically what I show in the demos on the website);

-          SCCM, Altiris, KACE, or similar;

-          Windows Intune, Airwatch, and Mobile Iron . . . if someone has already decided to use an MDM service;  

-          Or with PolicyPak Cloud if the IT team wants no infrastructure at all (or are MSPs).

Like I said, since Group Policy’s core is staying the same but isn’t updating some areas of Group Policy Preferences to accommodate Windows 8.1/10’s changes, then we step in to fix this.

As such, we’re days away from shipping our newest component, PolicyPak File Associations Manager, which fixes this problem thoroughly. And after the summer, we plan to release PolicyPak Start Menu Manager. We have more surprises, but those are the two I’m ready to talk about before they ship.

Q: Like me, you teach a lot of people around the world. Do you see people using MDM, InTune, and BYOD?

A: In my classes, when I ask, “Are you using Intune, Airwatch, MobileIron, . . . or something similar,” on average, two hands go up every class. Then I ask them, “Are you using it for Phones, Windows, or both?” Their answer every time is “only phones.”
I'm not trying to be a naysayer or bad guy or "pooh-pooh-er." This is just what I am seeing when I ask the question. You could argue, "Well, Jeremy, you ARE teaching a Group Policy class!" Well, actually, my class covers Group Policy and MDM in case people want information on both.

Also, it should be noted that Intune is a special case and has three ways it can be used. You can do a straight MDM join; you can get the SCCM client delivered through it and manage it using SCCM console; or you can install the “fat” Windows Intune MSI client. Even with these three different ways to use it, I simply don’t get people who are actively using it to manage Windows PCs.

Again, maybe I’m talking to the wrong population, or maybe I’m somehow in my own self-made bubble and thousands of happy customers are using it. But they don’t seem to be at my classes or at special events I do with larger audiences.

Q: So what is the future of MDM and Group Policy?

A: I cannot be sure of MDM, but I can be sure of Group Policy.

By which, I mean Group Policy is a known entity, which likely won’t change much more. This is both a pro and a con. It’s a Pro because it means it’s not constantly changing under your feet, requiring you to learn a new thing every 6-10 months or guess where the wind is going to blow. It’s a con because Microsoft knows about the rough edges in Group Policy/Group Policy Preferences and likely won’t fix them. But that’s okay too. Because for every rough edge I know about in Group Policy, we’re going  to smooth it out using PolicyPak. And, technically, other companies are welcome to do this too. Group Policy is and was very extensible from day one. MDM actually isn’t extensible today at all. If Microsoft doesn’t make and then ship the moving part (called the CSP), then there’s simply no way to do it using MDM. That could change in the future. But right now, what Microsoft ships is all that you get.

MDM, however, is a moving target. Because it’s getting active development, it’s hard to know where it might go. Again, the stated goal is NOT to bring over the Group Policy “baggage” from the past, yet when you ask IT admins what they want in modern management, they actually tend to explain scenarios and settings that are almost exactly like what we already have with on-prem Group Policy.

Maybe it’s because that’s what they already know; or maybe it’s because that management style works, or maybe some other reason.

In Windows 10, 1703 (Creators Update), they enabled a lot more policy settings in MDMland. But it’s still only a few hundred.

Again, if that’s all you need, then MDM is a fine choice. But if the admin really want the full control of the device, then I don’t think MDM can dislodge Group Policy’s place in the IT world in the foreseeable future.

If you’re not sick of this subject yet or if you want more detail from a different level, I would recommend checking out my “Why Group Policy Is Not Dead Manifesto” at https://www.gpanswers.com/the-why-group-policy-is-not-dead-manifesto/ .

Thanks for the Q&A, Sami. This was fun. If people want to sign up for Group Policy (and sometimes MDM tips) at www.GPanswers.com, we’d love to have them. And if people want to learn more about PolicyPak, watch our daily webinar at www.PolicyPak.com; it is the best first step.

Prevent interactive logon of Local Admins - Only allow UAC elevation

Hi again!

I've been asked this many times:"How can I block interactive logon of an admin account so they would just be able to use UAC?"

This is a good point as this will:

• Allow a user to use UAC-prompt to authorize admin procedures
• Not allow the user to actually start logging on as that user (as a convenience for themselves)

Windows does not allow the separation of a "UAC Logon" which is annoying as this would be great. So I can block logon interactively but the UAC won't work and if I want to allow UAC then they can always logon as well.

My trick on making this happen is to use AppLocker/SRP to block them from using the Explorer.exe or Task Manager. When they logon they get an empty screen with no ability to do anything. You could replace it with launching a custom shell as well and that shell would just show a note: "You are not allowed to logon interactively with this user!!"

So these are the rules I use:

The Fuzz about Terminal Services Session Hijacking

Hi!

I just wanted to take a short moment and tell everyone on my blog about the latest news about TS Session hijacking. Mainly noted here: http://www.korznikov.com/2017/03/0-day-or-feature-privilege-escalation.html

My two cents on this: "Calm down, Spread out, nothing to see here!"

This a normal feature of the OS that I use daily on my lab server where my students use VM's on. The OS is the same for the server and the client below the surface so you can do this on a client or a server for that reason. This "Feature" is known as shadowing.

Here's a few screen shots where I "HIJACK" a session and do "PRIVILEGE ELEVATION!!"

So any Admin can do this not just SYSTEM and not just with a Service.

With SYSTEM you get the privilege of attaching to disconnected sessions - that is a nice bonus. Just remember if you want to show the session hijack thing it's a lot easier by running PSEXEC -SID TASKMGR.exe
Then go to Users tab and choose who you want to be. No service needed and works on all OS's.

Also a good point once again that you can't allow Domain Admins to log on to normal workstations as they could be compromised and someone can use this trick against him.

Cheers,

Sami

Found a BUG in Windows Defender Anti-Tampering

Hi!

You should never logon to your Windows 10 as an Admin - You know I think so. Now it was just so amazingly funny when Avecto called me and asked to to do a webinar on this, which I delivered this week on Thursday. Like I (sadly) often do I just looked at what I was supposed to talk about a few days before primetime :) I just then realized it said "Sami Will show how to disable anti-malware"... Uups... I didn't really know exactly how to do it as I haven't tried in a long time to block Windows Defender.. Microsoft has done a good job with the Anti-Tampering anyway so I was honestly a bit worried...

Then I told myseld what I keep telling you: "If you are an Admin you can anyway do whatever you want". And for sure it took me like 5 minutes to come up with a way to totally block Defender. No, not just make it silent in the background, I mean really block it :)

Here is a video on how to do it:


How to mitigate? Don't run as an admin!