-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
$HoneyPotDirectoryNamePattern misses entries beginning with a period #4
Comments
That's a good catch. I'll look into it and either update honey pot handling or blame it on PowerShell. |
Working towards a solution: I was testing doing a Get-ChildItem. I didn't realize that it could return more than one type. I'm an old C hack, a current Python hack, and I hate PowerShell so I don't expect this aberrant behavior. If I used a filter that returned only a single matching directory it was type System.IO.FileSystemInfo but if I had multiple hits it returned a type System.Array. Took me a stupid amount of time to figure out but I'm on the golden path now. Now we'll cast our results as an array by doing something like this: The point of all this array casting is that we can't assume the number of hits the first Get-ChildItem will return, and by inference, the data type of the return. The second item's cast is just for belt and suspenders. I know exactly what data type I want so we'll be explicit in the code. @("hoopdy","doo"). Take that ambiguity! Matching the honeypot directories that begin with a dot is a little weird. We can sometimes pretend the dot is an actual character, but not with wildcard matching. Other times it means this directory. And still other times it means, "Hey, everything after me is a file name extension and I'm just a place holder." So why are we even bothering instead of just saying this is a special case that we are going to ignore? Macs and *nix, that's why. And because I hate PowerShell and love my Mac/Linux systems. Capricious? Sure. Will it hurt the non-Mac and non-Linux systems? Nope, they won't act any differently. And it's a challenge. That's why. Let's do this! Steps to do - we tear into the actual script code and do four things:
Finally, this is really just a rambling note so that if I procrastinate I'll know where to pick this up later. |
No longer considering this a bug. It's really normal Windows behavior. I just don't like it so we're going to work around it. |
Awesome, thanks! I'm sure I found the only character PowerShell doesn't like as a character to start a directory name and I always seem to run into obscure issues like this one. I'm not really a coder myself, just able to hack around existing code if needed. |
Testing new code. |
Added option to include honey pot directories that begin with a leading dot. Really great suggestion. Thanks. |
I know this is more of a PowerShell bug, but thought I should bring it to your attention in case it could be fixed somehow. Some of my honeypot directory names begin with a period to also hide them from Macs in our mixed Windows/Mac environment.
Line 494 of FSRM-Anti-ransomware.ps1:
ForEach-Object -Process {Get-ChildItem -Path $_.Path -Force -ErrorAction SilentlyContinue -Directory -Filter $HoneyPotDirectoryNamePattern} |
When setting $HoneyPotDirectoryNamePattern to ??Directory, it does not match ones that begin with a period.
Example in straight PS:
Changing the filter to include any length beginning character with an asterisk will then show the missing directories
My workaround right now is to use *VerySpecificDirectoryName as $HoneyPotDirectoryNamePattern
The text was updated successfully, but these errors were encountered: