├── MISG ├── BasePolicy-Audit │ ├── SIPolicy.p7b │ ├── MISGbase-v1-audit.bin │ └── MISGbase-v1-audit.xml ├── BasePolicy-Enforced │ ├── SIPolicy.p7b │ ├── MISGbase-v1-enforced.bin │ └── MISGbase-v1-enforced.xml ├── BPwithMSblockrules-Audit │ ├── SIPolicy.p7b │ └── MISGbasewithmsblocks-v1-audit.bin ├── BPwithMSblockrules-Enforced │ ├── SIPolicy.p7b │ ├── MISGbasewithmsblocks-v1-enforced.bin │ └── MISGbasewithmsblocks-v1-enforced.xml └── README.md ├── Customized Block Rulesets ├── Enhanced Rules - Balanced │ ├── balanced policy files │ │ ├── enhanced-balanced--audit.bin │ │ └── enhanced-balanced--enforced.bin │ └── readme.md ├── Enhanced Rules - Cautious │ ├── cautious policy files │ │ ├── enhanced-cautious--audit.bin │ │ └── enhanced-cautious--enforced.bin │ └── notes.md └── readme.md ├── HighlyDeployableWDACPolicies-Experimental ├── CorePolicySets │ ├── Audit │ │ ├── {A5C89FE7-C0F8-492A-A1DC-240F472AB1B6}.cip │ │ └── {C1D4CB32-43F2-420E-9C96-AA1E5CBD8251}.cip │ └── Enforced │ │ ├── {74728A3E-D2F8-4AB3-B774-C639E8F62BB4}.cip │ │ └── {A67929A2-9A4B-4449-9447-C16627E16DF7}.cip ├── StandardPolicySets │ ├── Audit │ │ ├── {485F1632-82BF-4A1E-9647-BC2A1EC56C3F}.cip │ │ └── {67958FD3-74F7-4EE4-BF56-7BB477A42F03}.cip │ └── Enforced │ │ ├── {8938FDB5-3D7D-41FA-9B3C-C4AB3D097A60}.cip │ │ └── {9CCF7383-3747-4A8D-B8D8-A33183999E00}.cip ├── CorePolicySets-DisabledSE │ ├── Audit │ │ ├── {712B6D27-F2BD-4ABA-A5F6-8F313B0E3CE1}.cip │ │ └── {FD2E3AA8-3A16-4EF3-981F-7090CEFD0AAC}.cip │ └── Enforced │ │ ├── {0D24A78B-1E40-4B8C-9993-0E0D4FF71DB5}.cip │ │ └── {7B4F5FE1-A8EA-47F6-B7DA-A18383F66CC0}.cip ├── StandardPolicySets-DisabledSE │ ├── Audit │ │ ├── {56B8D812-794E-4FDF-9666-AE00E9F4F28F}.cip │ │ └── {8151142D-0374-4131-8759-8025FA45EAAF}.cip │ └── Enforced │ │ ├── {1EB0B755-BCA9-4AB4-B989-29473C1ED890}.cip │ │ └── {3626455A-7DF6-4BA8-8E45-1799D8121B19}.cip └── README.md └── README.md /MISG/BasePolicy-Audit/SIPolicy.p7b: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BasePolicy-Audit/SIPolicy.p7b -------------------------------------------------------------------------------- /MISG/BasePolicy-Enforced/SIPolicy.p7b: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BasePolicy-Enforced/SIPolicy.p7b -------------------------------------------------------------------------------- /MISG/BPwithMSblockrules-Audit/SIPolicy.p7b: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BPwithMSblockrules-Audit/SIPolicy.p7b -------------------------------------------------------------------------------- /MISG/BasePolicy-Audit/MISGbase-v1-audit.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BasePolicy-Audit/MISGbase-v1-audit.bin -------------------------------------------------------------------------------- /MISG/BPwithMSblockrules-Enforced/SIPolicy.p7b: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BPwithMSblockrules-Enforced/SIPolicy.p7b -------------------------------------------------------------------------------- /MISG/BasePolicy-Enforced/MISGbase-v1-enforced.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BasePolicy-Enforced/MISGbase-v1-enforced.bin -------------------------------------------------------------------------------- /MISG/BPwithMSblockrules-Audit/MISGbasewithmsblocks-v1-audit.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BPwithMSblockrules-Audit/MISGbasewithmsblocks-v1-audit.bin -------------------------------------------------------------------------------- /MISG/BPwithMSblockrules-Enforced/MISGbasewithmsblocks-v1-enforced.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/MISG/BPwithMSblockrules-Enforced/MISGbasewithmsblocks-v1-enforced.bin -------------------------------------------------------------------------------- /Customized Block Rulesets/Enhanced Rules - Balanced/balanced policy files/enhanced-balanced--audit.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/Customized Block Rulesets/Enhanced Rules - Balanced/balanced policy files/enhanced-balanced--audit.bin -------------------------------------------------------------------------------- /Customized Block Rulesets/Enhanced Rules - Cautious/cautious policy files/enhanced-cautious--audit.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/Customized Block Rulesets/Enhanced Rules - Cautious/cautious policy files/enhanced-cautious--audit.bin -------------------------------------------------------------------------------- /Customized Block Rulesets/Enhanced Rules - Balanced/balanced policy files/enhanced-balanced--enforced.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/Customized Block Rulesets/Enhanced Rules - Balanced/balanced policy files/enhanced-balanced--enforced.bin -------------------------------------------------------------------------------- /Customized Block Rulesets/Enhanced Rules - Cautious/cautious policy files/enhanced-cautious--enforced.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/Customized Block Rulesets/Enhanced Rules - Cautious/cautious policy files/enhanced-cautious--enforced.bin -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Audit/{A5C89FE7-C0F8-492A-A1DC-240F472AB1B6}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Audit/{A5C89FE7-C0F8-492A-A1DC-240F472AB1B6}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Audit/{C1D4CB32-43F2-420E-9C96-AA1E5CBD8251}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Audit/{C1D4CB32-43F2-420E-9C96-AA1E5CBD8251}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Enforced/{74728A3E-D2F8-4AB3-B774-C639E8F62BB4}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Enforced/{74728A3E-D2F8-4AB3-B774-C639E8F62BB4}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Enforced/{A67929A2-9A4B-4449-9447-C16627E16DF7}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets/Enforced/{A67929A2-9A4B-4449-9447-C16627E16DF7}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Audit/{485F1632-82BF-4A1E-9647-BC2A1EC56C3F}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Audit/{485F1632-82BF-4A1E-9647-BC2A1EC56C3F}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Audit/{67958FD3-74F7-4EE4-BF56-7BB477A42F03}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Audit/{67958FD3-74F7-4EE4-BF56-7BB477A42F03}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Enforced/{8938FDB5-3D7D-41FA-9B3C-C4AB3D097A60}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Enforced/{8938FDB5-3D7D-41FA-9B3C-C4AB3D097A60}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Enforced/{9CCF7383-3747-4A8D-B8D8-A33183999E00}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets/Enforced/{9CCF7383-3747-4A8D-B8D8-A33183999E00}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Audit/{712B6D27-F2BD-4ABA-A5F6-8F313B0E3CE1}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Audit/{712B6D27-F2BD-4ABA-A5F6-8F313B0E3CE1}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Audit/{FD2E3AA8-3A16-4EF3-981F-7090CEFD0AAC}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Audit/{FD2E3AA8-3A16-4EF3-981F-7090CEFD0AAC}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Enforced/{0D24A78B-1E40-4B8C-9993-0E0D4FF71DB5}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Enforced/{0D24A78B-1E40-4B8C-9993-0E0D4FF71DB5}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Enforced/{7B4F5FE1-A8EA-47F6-B7DA-A18383F66CC0}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/CorePolicySets-DisabledSE/Enforced/{7B4F5FE1-A8EA-47F6-B7DA-A18383F66CC0}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Audit/{56B8D812-794E-4FDF-9666-AE00E9F4F28F}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Audit/{56B8D812-794E-4FDF-9666-AE00E9F4F28F}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Audit/{8151142D-0374-4131-8759-8025FA45EAAF}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Audit/{8151142D-0374-4131-8759-8025FA45EAAF}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Enforced/{1EB0B755-BCA9-4AB4-B989-29473C1ED890}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Enforced/{1EB0B755-BCA9-4AB4-B989-29473C1ED890}.cip -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Enforced/{3626455A-7DF6-4BA8-8E45-1799D8121B19}.cip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/arekfurt/WinAWL/HEAD/HighlyDeployableWDACPolicies-Experimental/StandardPolicySets-DisabledSE/Enforced/{3626455A-7DF6-4BA8-8E45-1799D8121B19}.cip -------------------------------------------------------------------------------- /Customized Block Rulesets/Enhanced Rules - Balanced/readme.md: -------------------------------------------------------------------------------- 1 | **"Balanced" Ruleset** 2 | 3 | More documentation coming soon. Suffice to say for now that, in addition to incorporating the rules in the "Cautious" ruleset, this ruleset currently: 4 | 5 | -blocks cmstp.exe (evasive way to download & execute scripts; being used in the wild) 6 | 7 | -blocks Flash in Powerpoint 8 | 9 | -blocks InstallUtil.exe (allows vectors of attack that can potentially abuse .Net to bypass whitelisting; worth doing at least until .Net hardening option actually works; most likely of these to have undesirable side effects on legitimate things) 10 | 11 | -blocks ability to use (via scrobj.dll, scrrun.dll, mshtml.dll) Squiblydoo with regasm.exe 12 | 13 | Mainly because of the block on InstallUtil.exe, I especially recommend testing this block ruleset in audit mode before enabling enforcement. At the least, I recommend being prepared to quickly remove an enforced policy from the CodeIntegrity folder and reboot on any or all machines an enforced policy is applied to in case problems arise. 14 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Windows Application Whitelisting/Application Control Notes and Sample Policies 2 | 3 | This repository contains (or, rather, as of this writing will contain) sample policies and some assorted notes related to some research into various capabilities of Windows Defender Application Control and AppLocker. Posting of any sample rulesets or policies here is meant to encourage, and perhaps make a bit easier, the work of those looking at implementing those technologies in their environments, and indicates that I've at least done some testing with them in my own lab environments and/or on my own personal devices. But I can make no assurance that anything here will work in your environments or on your equipment. And by "work" I mean "will not prevent your computer from booting or cause an important application to fail to run properly". 4 | 5 | **ALWAYS initially test "enforced" application whitelisting policies on test machines that you're willing and able to troubleshoot boot problems with. Expect that whitelisting policies may well cause unforeseen problems the first time they're taken from "audit" to "enforce". No matter how thorough the audit testing you may have done.** 6 | -------------------------------------------------------------------------------- /Customized Block Rulesets/Enhanced Rules - Cautious/notes.md: -------------------------------------------------------------------------------- 1 | **The "Cautious" Ruleset** 2 | 3 | This list draws the vast majority of its block rules from two sources: (1)Microsoft's recommended block list, all rules included, and; (2) a few different items of guidance produced on Device Guard (limited, admittedly) and EMET Attack Surface Reduction rules by the what used to be called the Information Assurance Division of the NSA (now NSA Cyber). These rules were chosen by Microsoft and the NSA, no doubt, with the aim of minimizing impact on the legitimate needs of the vast majority of users. However, beyond their concern with that I have been selective myself about which rules suggested by the NSA in their EMET ASR guidance to replicate. (For instance, the current version of this ruleset does not block Office applications from loading packager.dll, which would block malicious Office OLE attacks but while perhaps blocking some non-trivial amount legitimate use.) That said, I have added a few narrowly targeted rules of my own. 4 | 5 | This ruleset is likely to get more robust in the near future, rather than less so. Still, I intend this to remain an option that is decidedly conscious of avoiding "collateral damage." If you want something more protective but carries a bit more risk of unwanted negative side effects (although I believe still acceptable for most real world general use cases), check out my "balanced" custom ruleset. 6 | 7 | **Update (11/02/2018):** Cleaned the ruleset xml up a good bit, but didn't substantively change any of the rules. Thus, I'm keeping the "version" (if you want to use that term) at 1.0. Did add policy files incorporating the rules, which are just a product of merging the custom block ruleset with Microsft's AllowAll starter WDAC policy that ships with Win 10 Enterprise. Just in case anyone else wants to test out the block rules independently of any base whitelisting policy restrictions. 8 | _________________________________________________________ 9 | **What's different from the current (10/22/2018) Microsoft ruleset?** 10 | 11 | -blocks Squidblydoo (from @subtee) in rundll32.exe and regsvr32.exe (NSA EMET guidance) 12 | -blocks wdigest.dll (NSA WDAC guidance) 13 | -blocks Flash from loading in Word and Excel (but not Powerpoint) (NSA EMET guidance) 14 | -blocks scriptrunner.exe 15 | -blocks the mavinject.exe processes 16 | (background: https://posts.specterops.io/mavinject-exe-functionality-deconstructed-c29ab2cf5c0e ) 17 | 18 | 19 | Note: If the scriptrunner and/or mavinject rules are used on a machine running applications with AppV it's possible you could see an issue. (If you don't know or aren't quite sure what AppV is, you almost certainly don't have to worry about that. And you can always just copy a troublesome unsigned policy out of the CodeIntegrity folder and reboot. But when in doubt audit first.) 20 | -------------------------------------------------------------------------------- /Customized Block Rulesets/readme.md: -------------------------------------------------------------------------------- 1 | # Enhanced Block Lists for Restricting Risky Processes and Modules in Windows Defender Application Guard/Device Guard 2 | 3 | Microsoft publishes (at https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules) a list of Microsoft-produces executables (most built into Windows 10, some not but downloadable from MS) that it recommends you block if you're trying to create a robust application control policy with WDAC/DG because they can be abused to bypass restrictions and run arbitrary code. This list is fine as far as it goes (though no doubt there are other bypasses waiting to either be discovered or be made public), but it's definitely a bit on the conservative side in terms of blocking potential bypass hazards. Moreover, it doesn't really address any other important purposes of using block rules in WDAC/DG. Like preventing certain processes from loading specific dlls, add-ins, etc. that likely would only be used by those processes during malicious activity. After the release of new WDAC/DG capabilities in Windows 10 1703 and subsequent forced retirement of EMET on Windows 10, the supported way to restrict what modules can be loaded by what processes accross versions of Windows 10 today is to create WDAC block rules that do so. 4 | 5 | My aim here is to gradually publish a collection of improved block rulesets that use selective blocking of both processes and modules (largely dlls) to both guard against actual "bypass" techniques and restrict code execution mechanisms that may not technically count as hard bypasses but are abusable by real-world actors to evade application control and other defenses. (Or just overwhelmingly abused for malicious purposes in general.) These rulesets, just like the ruleset Microsoft produces, are primarily designed to be merged into other policies (for eg., one of the starter policies included with Win 10 Enterprise, or a policy you create by scanning a reference machine with Powershell scripts as described in the MS documentation at https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy ), not to be compiled and put into force on their own. However, because I think there is some utility to being able to test block rulesets independently of base WDAC whitelisting rules I'm including policy files that combine the block lists here with Microsoft's AllowAll base starter policy that ships with Windows 10 Enterprise. 6 | 7 | Some notes on the particular contents of the policies will be included in the sub-folders that contain them. 8 | 9 | **Note #1:** Unfortunately, as of this writing you still need a machine or VM running Windows 10 Enterprise to use the Powershell scripts that merge and compile WDAC/DG policies. Likewise, while you can always edit by hand the xml file of a sample/starter policy or even create your own from ground up, if you’d like to use the auto scanning & creation Powershell scripts MS has created you’ll currently need an install of Enterprise to do so. (Fortunately, you do have the ability to do a VM or dual-boot trial of Win 10 Enterprise for up to 180 days before Windows starts complaining about software validation.) 10 | 11 | **Note #2:** Also as of this writing, the "Disable:Script Enforcement" option that is documented in the official MS guidance does not actually work. The import of that is that putting *any* WDAC/DG policy into place and enforcing it will result in Powershell, WSH, etc. running in Constrained Language Mode. Even if you just want to selectively block certain module loads into certain processes that are usually initiated maliciously, as the old EMET Attack Surface Reduction capabilities allowed you to do. CLM being enforced may not be a dealkiller for you; indeed, for the large majority of general use PC setups it’s probably desirable. But if it is a dealkiller... well, as of now that means you have no usable successor to EMET ASR rules on Windows 10. As with the Enterprise policy creation restrictions, this is lousy. But for now it is what it is. (Going on to the Windows Feedback Hub and politely bugging MS to get this important setting working probably couldn't do any harm, though.) 12 | 13 | -------------------------------------------------------------------------------- /HighlyDeployableWDACPolicies-Experimental/README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # Deployability-Focused Windows Defender Application Control Starter Policies for Testing and Refinement 4 | 5 | ## IMPORTANT NOTE (07/23): 6 | Unfortunately, based on my own testing I cannot at this time recommend beginning to deploy *to production machines* WDAC policies that use the new capabilties available in Win10 1903, with the exception of pre-1903 compliant policies that (1) just use the newly working "Disable:Script Enforcement" option or (2) have Script Enforcment enabled but are known not to cause conflicts in your environments due to testing on previous versions of Windows 10. (But see Bug Note #2 below.) This caution does include within it any of the starter policies currently posted in this section of this repository. (Which are currently "beta" quality at most anyway.) This is due to certain WDAC bugs listed below, as well as some concerns I'll be intentionally vague about for now. However, I'm sure Microsoft is working to address the issues that exist, and I would encourage continued work developing and testing Win10 1903 WDAC policies with the intention of rolling them out for use in the near-ish future. (Notably, if you're a larger organization that has recently begun to evaluate Windows 10 1903 itself for eventual deployment many months/years down the road I'd expect you can basically ignore this.) 7 | 8 | _________________________________________________________________________________________________ 9 | 10 | Windows 10 1903 introduces several capabilities that offer the promise of (hopefully) significantly lightening the burdens of deploying and maintaining application whitelisting/application control without sacrificing too much security robustness. The starter policies offered here are designed to both provide some functioning examples of how some of these new capabilities--such as multiple policy support, the ability to create filepath allow rules for locations that are admin-write-only, and the ability to choose whether Constrained Language Mode will or will not be on--may be used. And also to provide some practical policies that can give those interested in getting started with WDAC policy auditing and customization for their environments a bit of a head start, in terms of lessening the overall amount of refinement work they'll need to put in to eventually get to policies that are really usable. (For detection in audit mode, or detection and blocking in enforced mode). 11 | 12 | Currently, four policy set combinations are here, with audit and enforced policies available for each. For each of these eight overall policy set options there are two .cip policy files (one main policy and one block list policy) for each: 13 | 14 | 1. A "Core" policy combo with Script Enforcement (ie. CLM) on. 15 | 2. A Core policy combo with Script Enforcement disabled. 16 | 3. A "Standard" policy combo (Core + Intelligent Security Graph authorization) with Script Enforcement on. **Recommended.** 17 | 4. A Standard policy combo with Script Enforcement disabled. 18 | 19 | Each policy also is accompanied by the .xml file that was compiled to create it. 20 | 21 | 22 | Another note: Any intended use of any such policies presumes ordinary users without security expertise do not have administrative rights. Users with administrative rights may run any files as they choose from filepath locations allowed in these policies. 23 | 24 | 25 | I have at least lightly tested these policies on both Windows 10 Enterprise and Windows 10 Pro test machines and personal devices. With reasonably fair results. That said, I'd call attention to the word "lightly" there. These are basically alpha quality policies at this point in terms of maturity. **These policies are for TESTING and to provide a starting basis for customization. Do not even think of putting them into enforced production use on important machines, at least without doing both extensive audit testing and refining and then a cautious enforced test deployment first.** Indeed, I include enforced versions of policies here largely because, in my experience with 1903 so far, there may be a few issues which, despite the best audit testing, only materialize once enforcement is turned on. 26 | 27 | In terms of which starter policy set is "best", there's clearly not one always-right answer. Personally, I tend to believe that having a good set of core allow rules, a good set of block rules, MISG authorization on to automatically allow many applications that have known good reputation to run, along with CLM/Script Enforcement enabled has perhaps the best potential to produce refined policies in many environments that are effective against the vast bulk of attacker malware threats in the wild while requiring as little effort required in creating, refining, and maintaining policies as possible. But your judgment and circumstances may vary, of course. Thus, there are options. (With more likely to come.) 28 | 29 | The core rules included in the policies here will most certainly evolve as I have time to further study and experiment with both enhancements to what they allow and to malicious behaviors they can block. (If you’re interested, keep an eye on the brand new dev branch to see what may be coming here.) 30 | 31 | Note: Any intended use of any such policies presumes ordinary users without security expertise do not have administrative rights. Users with administrative rights may run any files as they choose from filepath locations allowed in these policies. 32 | 33 | **Bug Note:** MS has confirmed that a bug exists that causes serious deauthorization issues of vital Windows components if you attempt to merge certain allow rule lists and certain deny rule lists. The rules used in these policies trigger this bug. **Until further notice, DO NOT MERGE THE MAIN AND BLOCK LIST POLICY FILES HERE.** Just use the two separate policies included for each policy combo. 34 | 35 | **Bug Note 2:** Currently (as of 7/23) when Script Enforcement is enabled not all things that would trigger it (if you're in audit mode) or do get blocked by it (if you're in enforced mode) are written to the AppLocker/MSI and Scripts log as they should be. This includes at least some blocking of scripts in .hta files (assuming you don't have mshta.exe blocked as an application), possibly some Powershell commands, and some wmic.exe and regsvr.exe commands that could sometimes be used to bypass pre-1903 versions of WDAC. 36 | 37 | ## July 15 Improvements 38 | 39 | -created new Core (ie. without MISG enabled)-Script Enforcement Disabled audit and enforced policy sets 40 | 41 | -merged in EKU and EKUCert-related signing stuff from official MS sample policies (hadn't done so previously due to bug assessment efforts) 42 | 43 | -recompiled all 16 (8 main, 8 block list) policies with new and unique GUIDs, descriptive names, and Policy ID strings 44 | 45 | -renamed files and folders descriptively 46 | 47 | -further tested policies (found and reported an apparent hta script enforcement logging bug to MS) 48 | 49 | -documentation improvements 50 | 51 | ## Block List Rules 52 | 53 | The block rule policies are currently identical for each policy set in what processes and modules they block, although not in the policy rule options they use. Use each block list file with its main policy file in the same folder. The core block list is based on the Microsoft recommended blocklist for Win 10 1903 (current as of July 5, 2019) except it also: 54 | 55 | -allows mshta and wmic 56 | (allowing actual use of mshta may also require "Disabled: Script Enforcement" option to be set) 57 | 58 | -blocks various older WDAC scripting bypasses using rundll32, regsvr, and regasm 59 | 60 | -blocks mavinject 61 | 62 | -blocks use of flash.ocx by Word and Excel 63 | 64 | -blocks cmstp 65 | 66 | -blocks wdigest 67 | 68 | ## Instructions 69 | Deploy these policies manually on a test machine by dropping the two .cip files for your choice of configuration, as appropriate, into the C:\Windows\System32\CodeIntegrity\CiPolicies\Active folder. **Do not rename the .cip policy files.** They must be named with their policy GUIDs to enable properly. (Note: For sake of simplicity the filepath rules in the policies currently assume your OS drive is the C: drive. I will attempt to switch to using environmental variables for future versions.) 70 | 71 | 72 | **Issue reports and specific suggestions for rules/etc. that you'd like to see included are very welcome. Pull requests welcome. Feedback in general is welcome.** 73 | -------------------------------------------------------------------------------- /MISG/BasePolicy-Enforced/MISGbase-v1-enforced.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 10.0.0.0 4 | {A244370E-44C9-4C06-B551-F6016E563076} 5 | {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 216 | 217 | 221 | 222 | 223 | 0 224 | 225 | 226 | 227 | DefaultWindowsAudit 228 | 229 | 230 | 231 | 232 | 031017 233 | 234 | 235 | 236 | -------------------------------------------------------------------------------- /MISG/BasePolicy-Audit/MISGbase-v1-audit.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 10.0.0.0 4 | {A244370E-44C9-4C06-B551-F6016E563076} 5 | {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 219 | 220 | 224 | 225 | 226 | 0 227 | 228 | 229 | 230 | DefaultWindowsAudit 231 | 232 | 233 | 234 | 235 | 031017 236 | 237 | 238 | 239 | -------------------------------------------------------------------------------- /MISG/README.md: -------------------------------------------------------------------------------- 1 | # Windows Defender Application Control + Microsoft Intelligent Security Graph App Reputation 2 | 3 | In the Windows 10 1709 release Microsoft introduced a new feature to the newly-renamed Windows Defender Application Control: the ability to allow any applications to run that have obtained positive application reputation in Microsoft's Intelligent Security Graph cloud service. In theory, WDAC (which now comprises most, but not all, of the functionality that used to fall under the label "Device Guard" pre-1709) when integrated with MISG could hold the potential to make adoption of application whitelisting much less painful for organizations and individuals by allowing commonly used Windows programs from reputable publishers to run without it being necessary to have specific, per-application or per-publisher rules for them specifically set out in a whitelisting policy. (MISG also helps power capabilities in Windows SmartScreen, Windows Defender AV, and Windows Defender ATP.) This collection of sample policies, related files, and assorted notes is the result of my somewhat newb-ish efforts to look at how well that promise is translating into practice so far. 4 | 5 | Currently, the policies hosted here are: 6 | 7 | -A baseline WDAC policy, in audit and enforced versions, that authorizes the components of Windows and enables MISG authorization for other programs. (Note: The particular WDAC options that are and are not included in this policy result from efforts to mitigate issues that I found during my testing. I'll post here a detailed explanation of what options I put in/left out and why shortly.) 8 | 9 | -That baseline policy merged with Microsoft's recommended process and script blocklist ( https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules ), in audit and enforced versions. 10 | 11 | I will be adding more polices and extending the documentation of what I've seen in my testing in the days/weeks/months to come. I more than welcome you to post any suggestions and especially your notes about aspects of the policies that are causing problems in your environment/s on the Issues page, and will try to respond to them in a timely manner. 12 | 13 | **IMPORTANT SECURITY NOTE #1:** Although it's not in any written documentation [at least as of 11/05/2018], according to a presentation given by Microsoft's Jeffery Sutherland at the Ignite 2018 conference on this topic ( video here: https://myignite.techcommunity.microsoft.com/sessions/64537#ignite-html-anchor ), an intentional "bypass" to MISG app reputation checking with WDAC exists in Windows 10. In short, where a user attempts to run a program from the Internet that lacks established reputation and gets a warning from the SmartScreen feature in Windows about that fact, if the user then chooses to click through that SmartScreen warning WDAC will--in theory--also allow that program to run. I say "in theory" because in my own testing thus far whether or not that actually happens has been somewhat unpredictable, with MISG enforcement being circumvented on some occasions but not others, and sometimes with no obvious reasons for the different behavior. That said, there's a pretty good chance that if you're implementing a WDAC with MISG policy in enforced mode you probably don't *want* a user's actions to easily render your policy protections moot. And my testing does confirm that even a standard user can trigger this “bypass”. 14 | 15 | Fortunately, stopping this seems as straightforward as setting the SmartScreen action setting for unknown applications from "warn" to "block". This can easily be done in the Windows Security Center UI locally, through group policy, and through other mechanisms. 16 | 17 | **IMPORTANT SECURITY NOTE #2:** 18 | The sample policies contained here are unsigned (and not backed by the Virtualization-Based Security protection that is available in Windows 10 if you meet the hardware requirements for it). This is a practical necessity here: If I signed these policies myself and set the policy options to require any new policies bear that same signature, it would become substantially more of a burden--though hardly impossible, assuming you can access a UEFI menu-- to deactivate or replace one of them on your own equipment when you wished to do so. But the fact they are unsigned is a double-edged sword. On the one hand, it is much easier to try out and then delete or replace a policy if it causes a problem, whether temporarily (see the “Concluding Implementation Advice” section below) or permanently. Microsoft has posted fairly straightforward instructions for doing so ( https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies ), but they essentially boil down to taking the SIPolicy.p7b file out of your CodeIntegrity folder and, if necessary, [EFI System Partition]\Microsoft\Boot folder and rebooting. On the other hand, this also means that a knowledgeable attacker who can gain administrative rights can do the same thing. As is true with pretty much all other application control/whitelisting regimes available (AppLocker, Carbon Black, etc.) besides WDAC/Device Guard, of course. 19 | 20 | In my own opinion, a reasonable course if you’re interested in the capabilities of WDAC/Device Guard to combat attackers who are able to gain admin rights is to first extensively test and then deploy unsigned WDAC policies, refine them and work out all significant compatibility issues that are apparent, and then deploy signed policies and configure VBS (on machines that support it). But if you’re inclined to take a more aggressive approach, there is as mentioned, a procedure that allows a locally-present user to disarm even a signed policy. (See the same link.) But I wouldn’t particularly recommend that, at least for organizations. 21 | 22 | ______________________________________________________________________________ 23 | **Fair Warning** 24 | 25 | Do not initially deploy "enforced" versions of even the unsigned sample/starter policies here to machines that you would be really disturbed to see not boot properly, be unable to run critical applications properly, etc. Even if you do first deploy the audit version of the policy on a machine and nothing vital shows up in the Windows CodeIntegrity event log as being problematic. Simply put, the CodeIntegrity log does not catch every issue that may render a machine unbootable. Moreover, complex applications can have a ton of components that can trip CodeIntegrity rules if they aren’t all registered and authorized correctly by MISG. **Test the enforced policies here on machines you use for TESTING things.** This is not one of those occasions where "Screw it. Let's just push this straight to production." is taking risks you probably want to take, at least if "production" is really important. 26 | 27 | ( If you do have boot issues, Matt Graeber has written a post that contains info that has been extremely helpful, at least for me, in troubleshooting them: https://posts.specterops.io/adventures-in-extremely-strict-device-guard-policy-configuration-part-1-device-drivers-fd1a281b35a8 ) 28 | 29 | ____________________________________________________________________________ 30 | **Instructions for Getting Up and Running with the MISG Policies Here** 31 | 32 | I've formulated and tested the following procedure with the aim of getting a common set of steps that will work across Windows 10 Enterprise, Windows 10 Pro, and, yes, Windows 10 Home. The procedure is a little clumsy, but (at least in my testing) it reliably works across the versions: 33 | 34 | 35 | **1.** Download the SIPolicy.p7b file for the policy you want to test and copy it into your C:/Windows/System32/CodeIntegrity directory. (If you use a different drive letter for your OS drive, obviously substitute that.) 36 | 37 | **2.** Open an elevated command or Powershell prompt and run the following commands: 38 | 39 | sc.exe start appidsvc 40 | 41 | sc.exe config appidsvc start= auto 42 | 43 | appidtel.exe start 44 | 45 | Respectively, these commands make sure the Application Identity Service--which is needed to interface with the MISG reputation service-- is started on the machine, set that service to start at boot from now on, and immediately start the appidtel executable. This isn't Microsoft's procedure for enabling MISG functionality, but I've had some issues with Microsoft's simpler version--basically, just run appidtel.exe--not working properly on Pro and Home. 46 | 47 | **3.** Reboot. Despite what MS says, in my experience a reboot is often necessary for WDAC + MISG to work properly, especially on non-Enterprise versions of Windows. Even if you have the "Enabled:Update Policy No Reboot" option in place, as these policies do. Note: This reboot may take substantially longer than a normal one if you have a driver issue that trips the "Enabled:Boot Audit on Failure" option. **I highly recommend you keep the Enabled:Boot Audit on Failure option in place, at least for initial testing of an enforced policy.** Better a device that boots slowly than not at all. 48 | 49 | **4.** If you're in audit mode, use your device normally and, at some point, begin to look for issues with legitimate software getting flagged as "unauthorized" in your CodeIntegrity log, as well as .msi and scripts flagged in the AppLocker log. (Which will get put there even if you don’t use AppLocker as such.) If you're in enforced mode, see if your machine boots (Note: I've selected options for these policies to try to minimize boot-stopping issues, and I think most PCs should start correctly, if sometimes a tad slowly, rather than failing to boot if there are issues. But no guarantees.), and then ascertain whether your PC is properly accessing the MISG service and approving known-good non-Windows applications. The easiest way to do that is to just open something you already have installed that absolutely should be common enough to be approved--like Google Chrome--and see whether WDAC blocks it. 50 | 51 | **5.** Determine how suitable WDAC + MISG is for your needs by testing applications and drivers you need to have in your environment. Keep in mind that expecting perfection--meaning you would need to expend no effort whatsoever to tailor a baseline WDAC policy to your needs thanks to MISG auto-authorization of all desired programs--will often be unrealistic. Also consider how much you care about the inherent increase in exposure to "living off the land"/LoLbin bypass techniques that relying on something like MISG authorization brings vs. only using specific rules. (The counter-consideration, of course, is that use of MISG may make deploying application control feasible for you where it otherwise wouldn't be.) 52 | ____________________________________________________________________________ 53 | **Troubleshooting** 54 | 55 | -If your device has trouble booting, access your advanced boot options menu (or a recovery menu), open a command prompt, and delete the SIPolicy.p7b file. Since signature enforcement for the policy isn't turned on, rebooting the machine will return it to normal. Then take a look at the CodeIntegrity log and the other logging info Matt Graeber discusses in the link mentioned above. 56 | 57 | 58 | -If programs that you know *must* have positive MISG reputation are still being blocked by WDAC, and you have go Internet connectivity, there’s a good chance that your device's AppID components aren't configured as they need to be. One trick that resolved this problem once or twice for me (but often doesn't seem to be necessary): create a scheduled task to actually run appidtel.exe at startup, every time. Otherwise, make sure the Appidsvc service is running by looking at Task Manager or the Services control panel, and beyond that... well, Google and MS tech forums are your friends for diagnosing AppID component problems. 59 | 60 | -In some cases, the primary executable for a program will be authorized by MISG but something will still go wrong when it runs, causing a crash, broken functionality, error messages, etc. Presumably ,as I mentioned, this is due to components of the program not being authorized even though the primary executable is. Not much you can do with these situations if you need the application to work, except go through one of the WDAC policy processes that will result in creating specific rules for the program. Note: The error messages popped by a malfunctioning program due to this may be somewhat misleading about the cause. For example, the current universal Windows Firefox installer [tested as of 10/05/2018] is authorized by MISG but fails with an error about how Firefox requires Windows 7 or higher. 61 | 62 | ____________________________________________________________________________ 63 | **Resources** 64 | 65 | -Microsoft's official guidance on WDAC isn't always complete (despite its length) and isn't always clear. But, at the least, the section called the "Windows Defender Application Control deployment guide" is essential reading if you're going to do any work with WDAC. Really, though, that stuff makes much more sense and is placed in context by the "design guide" that comes before it and describes (among other significant things) how WDAC policies work. Worth at least skimming the whole thing, really: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control 66 | 67 | -Among outside researchers, Matt Graeber (as mentioned) has done a ton of indispensable work on Device Guard/WDAC. You won't go wrong reading any or all of it. This item contains links to the bulk of his highly useful research on the topic (while also highlighting some of WDAC's shortcomings): http://www.exploit-monday.com/2018/06/device-guard-and-application.html 68 | 69 | ____________________________________________________________________________ 70 | **Concluding Implementation Advice** 71 | 72 | -Thus far in my testing, WDAC with MISG integration has worked considerably better in my testing as a as a “lockdown” mechanism versus starting with a fresh OS installation and adding software. By that I mean that I have found it better to install the software you need on a machine and then enforce a WDAC + MISG policy, rather than putting an enforced policy in place first and then trying to download and install the software you need. Ideally, this wouldn’t be the case; certainly it would be preferable to start with a policy in place and be able to leave it in place. And I’m sure Microsoft is working toward that end. However, for the present--and, again, in my experience--MISG app reputation authorization seems far better at allowing already installed software to run than it is with allowing installers to run and complete their work successfully. 73 | 74 | -If you have problems installing software that you know must have positive app reputation, using a direct download, full-size traditional installer version instead of a modern “skinny installer” that downloads components from the web can often help, I’ve found. But not always. [See my 11/01/2018 note on Adobe Reader below.] 75 | 76 | -It is fortunate that if you’re locally administering a machine and using an unsigned, enforced WDAC policy it is generally quite feasible to occasionally disable an the policy, install the software you need, and reenable that policy. Reboots may be required, but otherwise things aren’t too painful. On a standalone machine. However, trying to manage that at deployment scale in an organization, using Group Policy, Intune, scripts, or whatever, is likely to be a different ballgame. Another good reason to ensure that you go through a good testing process for all changes to enforced policies on representative test machines before deployment if you’re in an organization that, well, really cares about things working. 77 | 78 | ____________________________________________________________________________ 79 | **What Are Some Common Applications that Have Problems with WDAC + MISG? (As of the Date Specified)** 80 | 81 | For the reader's information, these are some significant issues that I've encountered in my test environment/s. I make no absolute guarantee that they would be replicated in yours. But, at least, they're things to watch out for. 82 | 83 | - Firefox Windows common installer: runs but fails to install successfully. (10/05/2018) 84 | (Note: Firefox browser itself works fine, though. As does the setup extractor for the Firefox Portable version.) 85 | - Opera browser installer: runs but fails to install properly. (The installed browser sort-of works, though with errors.) (10/05/2018) 86 | - VirtualBox (WDAC + MISG still hates, hates, hates VirtualBox. If you have it installed be prepared to deal with tons of error messages about VB components in the CodeIntegrity & AppLocker logs until you create specific rule/s to allow them.) (10/05/2018) 87 | - Adobe Reader’s “skinny installer” and directly downloaded full-size installers run but do not successfully complete installation. (11/01/2018) 88 | - Humorously, the process that hosts the Windows Event Viewer, mmc.exe, tries to load unauthorized components every time Event Viewer is opened. These being blocked does not seem to actually impact Event Viewer/MMC functionality, at least as far as I have seen. But it will be one of a number of sources of unauthorized loading attempts by stock Windows components that will clutter up your logs. (11/05/2018) 89 | 90 | 91 | 92 | -------------------------------------------------------------------------------- /MISG/BPwithMSblockrules-Enforced/MISGbasewithmsblocks-v1-enforced.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 10.0.0.0 4 | {A244370E-44C9-4C06-B551-F6016E563076} 5 | {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | 346 | 347 | 348 | 349 | 350 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | 392 | 393 | 394 | 395 | 396 | 397 | 398 | 399 | 400 | 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | 448 | 449 | 450 | 451 | 452 | 453 | 454 | 455 | 456 | 457 | 458 | 459 | 460 | 461 | 462 | 463 | 464 | 465 | 466 | 467 | 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | 477 | 478 | 479 | 480 | 481 | 482 | 483 | 484 | 485 | 486 | 487 | 488 | 489 | 490 | 491 | 492 | 493 | 494 | 495 | 496 | 497 | 498 | 499 | 500 | 501 | 502 | 503 | 504 | 505 | 506 | 507 | 508 | 509 | 510 | 511 | 512 | 513 | 514 | 515 | 516 | 517 | 518 | 519 | 520 | 521 | 522 | 523 | 524 | 525 | 526 | 527 | 528 | 529 | 530 | 531 | 532 | 533 | 534 | 535 | 536 | 537 | 538 | 539 | 540 | 541 | 542 | 543 | 544 | 545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 | 555 | 556 | 557 | 558 | 559 | 560 | 561 | 562 | 563 | 564 | 565 | 566 | 567 | 568 | 569 | 570 | 571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 | 595 | 596 | 597 | 598 | 599 | 600 | 601 | 602 | 603 | 604 | 605 | 606 | 607 | 608 | 609 | 610 | 611 | 612 | 613 | 614 | 615 | 616 | 617 | 618 | 619 | 620 | 621 | 622 | 623 | 624 | 625 | 626 | 627 | 628 | 629 | 630 | 631 | 632 | 633 | 634 | 635 | 636 | 637 | 638 | 639 | 640 | 641 | 642 | 643 | 644 | 645 | 646 | 647 | 648 | 649 | 650 | 651 | 652 | 653 | 654 | 655 | 656 | 657 | 658 | 659 | 660 | 661 | 662 | 663 | 664 | 665 | 666 | 667 | 668 | 669 | 670 | 671 | 672 | 673 | 674 | 675 | 676 | 677 | 678 | 679 | 680 | 681 | 682 | 683 | 684 | 685 | 686 | 687 | 688 | 689 | 690 | 691 | 692 | 693 | 694 | 695 | 696 | 697 | 698 | 699 | 700 | 701 | 702 | 703 | 704 | 705 | 706 | 707 | 708 | 709 | 710 | 711 | 712 | 713 | 714 | 715 | 716 | 717 | 718 | 719 | 720 | 721 | 722 | 723 | 724 | 725 | 726 | 727 | 728 | 729 | 730 | 731 | 732 | 733 | 734 | 735 | 736 | 737 | 738 | 739 | 740 | 741 | 742 | 743 | 744 | 745 | 746 | 747 | 748 | 749 | 750 | 751 | 752 | 753 | 754 | 755 | 756 | 757 | 758 | 759 | 760 | 761 | 762 | 763 | 764 | 765 | 766 | 767 | 768 | 769 | 770 | 771 | 772 | 773 | 774 | 775 | 776 | 777 | 778 | 779 | 780 | 781 | 782 | 783 | 784 | 785 | 786 | 787 | 788 | 789 | 790 | 791 | 792 | 793 | 794 | 795 | 796 | 797 | 798 | 799 | 800 | 801 | 802 | 803 | 804 | 805 | 806 | 807 | 808 | 809 | 810 | 811 | 812 | 813 | 814 | 815 | 816 | 817 | 818 | 819 | 820 | 821 | 822 | 823 | 824 | 825 | 826 | 827 | 828 | 829 | 830 | 831 | 832 | 833 | 834 | 835 | 836 | 837 | 838 | 839 | 840 | 841 | 842 | 843 | 844 | 845 | 846 | 847 | 848 | 849 | 850 | 851 | 852 | 853 | 854 | 855 | 856 | 857 | 858 | 859 | 860 | 861 | 862 | 863 | 864 | 865 | 866 | 867 | 868 | 869 | 870 | 871 | 872 | 873 | 874 | 875 | 876 | 877 | 878 | 879 | 880 | 881 | 882 | 883 | 884 | 885 | 886 | 887 | 888 | 889 | 890 | 891 | 892 | 893 | 894 | 895 | 896 | 897 | 898 | 899 | 900 | 901 | 902 | 903 | 904 | 905 | 906 | 907 | 908 | 909 | 910 | 911 | 912 | 913 | 914 | 915 | 916 | 917 | 918 | 919 | 920 | 921 | 922 | 923 | 924 | 925 | 926 | 927 | 928 | 929 | 930 | 931 | 932 | 933 | 934 | 935 | 936 | 937 | 938 | 939 | 940 | 941 | 942 | 943 | 944 | 945 | 946 | 947 | 948 | 949 | 950 | 951 | 952 | 953 | 954 | 955 | 956 | 957 | 958 | 959 | 960 | 961 | 962 | 963 | 964 | 965 | 966 | 967 | 968 | 969 | 970 | 971 | 972 | 973 | 974 | 975 | 976 | 977 | 978 | 979 | 980 | 981 | 982 | 983 | 984 | 985 | 986 | 987 | 988 | 989 | 990 | 991 | 992 | 993 | 994 | 995 | 996 | 997 | 998 | 999 | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 | 1009 | 1010 | 1011 | 1012 | 1013 | 1014 | 1015 | 1016 | 1017 | 1018 | 1019 | 1020 | 1021 | 1022 | 1023 | 1024 | 1025 | 1026 | 1027 | 1028 | 1029 | 1030 | 1031 | 1032 | 1033 | 1034 | 1035 | 1036 | 1037 | 1038 | 1039 | 1040 | 1041 | 1042 | 1043 | 1044 | 1045 | 1046 | 1047 | 1048 | 1049 | 1050 | 1051 | 1052 | 1053 | 1054 | 1055 | 1056 | 1057 | 1058 | 1059 | 1060 | 1061 | 1062 | 1063 | 1064 | 1065 | 1066 | 1067 | 1068 | 1069 | 1070 | 1071 | 1072 | 1073 | 1074 | 1075 | 1076 | 1077 | 1078 | 1079 | 1080 | 1081 | 1082 | 1083 | 1084 | 1085 | 1086 | 1087 | 1088 | 1089 | 1090 | 1091 | 1092 | 1093 | 1094 | 1095 | 1096 | 1097 | 1098 | 1099 | 1100 | 1101 | 1102 | 1103 | 1104 | 1105 | 1106 | 1107 | 1108 | 1109 | 1110 | 1111 | 1112 | 1113 | 1114 | 1115 | 1116 | 1117 | 1118 | 1119 | 1120 | 1121 | 1122 | 1123 | 1124 | 1125 | 1126 | 1127 | 1128 | 1129 | 1130 | 1131 | 1132 | 1133 | 1134 | 1135 | 1136 | 1137 | 1138 | 1139 | 1140 | 1141 | 1142 | 1143 | 1144 | 1145 | 1146 | 1147 | 1148 | 1149 | 1150 | 1151 | 1152 | 1153 | 1154 | 1155 | 1156 | 1157 | 1158 | 1159 | 1160 | 1161 | 1162 | 1163 | 1164 | 1165 | 1166 | 1167 | 1168 | 1169 | 1170 | 1171 | 1172 | 1173 | 1174 | 1175 | 1176 | 1177 | 1178 | 1179 | 1180 | 1181 | 1182 | 1183 | 1184 | 1185 | 1186 | 1187 | 1188 | 1189 | 1190 | 1191 | 1192 | 1193 | 1194 | 1195 | 1196 | 1197 | 1198 | 1199 | 1200 | 1201 | 1202 | 1203 | 1204 | 1205 | 1206 | 1207 | 1208 | 1209 | 1210 | 1211 | 1212 | 1213 | 1214 | 1215 | 1216 | 1217 | 1218 | 1219 | 1220 | 1221 | 1222 | 1223 | 1224 | 1225 | 1226 | 1227 | 1228 | 1229 | 1230 | 1231 | 1232 | 1233 | 1234 | 1235 | 1236 | 1237 | 1238 | 1239 | 1240 | 1241 | 1242 | 1243 | 1244 | 1245 | 1246 | 1247 | 1248 | 1249 | 1250 | 1251 | 1252 | 1253 | 1254 | 1255 | 1256 | 1257 | 1258 | 1259 | 1260 | 1261 | 1262 | 1263 | 1264 | 1265 | 1266 | 1267 | 1268 | 1269 | 1270 | 1271 | 1272 | 1273 | 1274 | 1275 | 1276 | 1277 | 1278 | 1279 | 1280 | 1281 | 1282 | 1283 | 1284 | 1285 | 1286 | 1287 | 1288 | 1289 | 1290 | 1291 | 1292 | 1293 | 1294 | 1295 | 1296 | 1297 | 1298 | 1299 | 0 1300 | 1301 | 1302 | 1303 | DefaultWindowsAudit 1304 | 1305 | 1306 | 1307 | 1308 | 031017 1309 | 1310 | 1311 | 1312 | --------------------------------------------------------------------------------