The purpose of the script is to check for vulnerabilities and common misconfigurations with Windows and installed applications. These issues can be abused by hackers or disgruntled workers providing privilege escalation routes from user to system and ultimately Domain Admin. ​ The vulnerability script has been tested on the latest versions of Windows 10, 11 and Server with PowerShell version 5.1 and outputs an HTML page. ​ Do not make changes to your IT systems based on the output of this report without a backup or testing, some of the suggestions are aimed at Domain joined clients and are likely to prevent Linux or legacy services from connecting to the domain. #Downloading and Executing the Script Download Tenaka/SecureReport (github.com), then as an elevated user open with PowerShell_ise, Ctrl, A and then F8. The report will take a while to execute, potentially up to 30 minutes, please be patient. The report is saved to C:\Securereport\FinishedReport.htm ​ Before everyone gets critical regarding the script formatting, some are due to how ConvertTo-HTML expects the data, most are to help those that aren’t familiar with scripting. There is a conscious decision not to use aliases or abbreviations and where possible to create variables. ​ #List of checks and balances: Host Details, CPU, Bios, Windows Version Accounts, Groups and Password Policy Install Applications and installed Windows Updates Virtualization, UEFI, Secure Boot, DMA, TPM and Bitlocker Settings LSA, DLL Safe Search Order, Hypervisor Code Integrity DLL Hijacking Files not Signed (Authenticode) Autologon Credentials in the Registry Unquoted paths Processes that contain passwords in the command line Enabled legacy Network protocols Registry Keys with weak Permissions System Folders with weak Permissions Drivers not Signed Authenticode Hash Mis-Match Firewall settings and rules ​ ​#TPM and Bitlocker "TPM and Bitlocker protect against offline attack from USB and mounting the local Windows system then accessing the local data. 'TPM and Pin' enhances Bitlocker by preventing LPC Bus (Low Pin Count) bypasses of Bitlocker with TPM. Further information can be found @ https://www.tenaka.net/bitlocker #Secure Boot Secure Boot is a security standard to ensure only trusted OEM software is allowed at boot. At startup, the UEFI and boot software's digital signatures are validated preventing rootkits More on Secure Boot can be found @ https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF #VBS Virtualization-based security (VBS), isolates core system resources to create secure regions of memory. Enabling VBS allows for Hypervisor-Enforced Code Integrity (HVCI), Device Guard and Credential Guard. Further information can be found @ https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://www.tenaka.net/deviceguard-vs-rce https://www.tenaka.net/pass-the-hash ​ #Hypervisor Enforced Code Integrity Hypervisor Enforced Code Integrity prevents the loading of unsigned kernel-mode drivers and system binaries from being loaded into system memory. Further information can be found @ https://docs.microsoft.com/en-us/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity #Security Options Prevent credential relay with Impacket and Man in the Middle by Digitally Signing for SMB and LDAP connections enforcement. Further information can be found @ https://www.tenaka.net/smb-relay-attack #LSA Enabling RunAsPPL for LSA Protection allows only digitally signed binaries to load as a protected process preventing credential theft and access by code injection and memory access by processes that aren’t signed. Further information can be found @ https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection #DLL Safe Search When applications do not fully qualify the DLL path and instead allow searching the default behaviour if for the ‘Current Working Directory’ called 2nd in the list of directories. This allows an easy route to call malicious DLLs. Setting ‘DLL Safe Search’ mitigates the risk by moving CWD to later in the search order. ​ Further information can be found @ https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order ​ #DLL Hijacking (Permissions) DLL Hijacking is when a malicious DLL replaces a legitimate DLL due to a path vulnerability. A program or service makes a call on that DLL gaining the privileges of that program or service. Additionally missing DLL's present a risk where a malicious DLL is dropped into a path where no current DLL exists but the program or service is making a call to that non-existent DLL. This audit is reliant on programs being launched so that DLLs are loaded. Each process’s loaded DLL's are checked for permissions issues and whether they are signed. The DLL hijacking audit does not currently check for missing DLL's being called. Process Monitor filtered for ‘NAME NOT FOUND’ and the path ends with ‘DLL’. #Automatically Elevate User Auto Elevate User is a setting that elevates users allowing them to install software without being an administrator. #Password in Files Searches the following locations: C:\Users\ C:\ProgramData\ C:\Windows\System32\Tasks\ C:\Windows\Panther\ C:\Windows\system32\ C:\Windows\system32\sysprep Searches the following file extensions: txt, ini, .xml ​ For the following words: password, credential ​ Ignore these files as they contain the word 'Password' by default: C:\Windows\system32\NarratorControlTemplates.xml C:\Windows\system32\DDFs\NGCProDDF_v1.2_final.xml C:\Windows\system32\icsxml\ipcfg.xml C:\Windows\system32\icsxml\pppcfg.xml C:\Windows\system32\slmgr\0409\slmgr.ini C:\Windows\system32\winrm\0409\winrm.ini ​ #Password embedded in Processes Processes that contain credentials to authenticate and access applications. Launching Task Manager, Details and add ‘Command line’ to the view. ​ #AutoLogon Checks "HKLM:\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" for any clear text credentials remaining from a MECM\SCCM\MDT deployment. #Unquoted The Unquoted Path vulnerability is when a Windows Service's 'Path to Executable' contains spaces and is not wrapped in double-quotes providing a route to System. Further information can be found @ https://www.tenaka.net/unquotedpaths ​ #Legacy Network Protocols LLMNR and other legacy network protocols can be used to steal password hashes. Further information can be found @ https://www.tenaka.net/responder #Permissions Weakness in Default System Directories - Write System default Folders that allow a User the Write permissions. These can be abused by creating content in some of the allowable default locations. Prevent by applying Execution controls eg Applocker. ​ Searches: C:\PerfLogs C:\Program Files C:\Program Files (x86) C:\Windows ​ Expected folders that a user can Write to: 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 Further information can be found @ https://www.tenaka.net/unquotedpaths https://www.tenaka.net/applockergpo ​ #Permissions Weakness in Default System Directories - Create Files System default Folders that allow a User the CreateFile permissions. These can be abused by creating content in some of the allowable default locations. Prevent by applying Execution controls eg Applocker. Expected folders that a user can CreateFiles to: C:\Windows\PLA\ReportsC:\Windows\PLA\Reports\en-GB C:\Windows\PLA\Reports\en-US C:\Windows\PLA\RulesC:\Windows\PLA\Rules\en-GB C:\Windows\PLA\Rules\en-US C:\Windows\PLA\Templates C:\Windows\Registration\CRMLog C:\Windows\System32\Com\dmp C:\Windows\System32\spool\drivers\color C:\Windows\System32\spool\PRINTERS C:\Windows\System32\spool\SERVERS C:\Windows\SysWOW64\Com\dmp C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System C:\Windows\TasksC:\Windows\Temp C:\Windows\Temp\MsEdgeCrashpad C:\Windows\Temp\MsEdgeCrashpad\reports ​ Further information can be found @ https://www.tenaka.net/unquotedpaths https://www.tenaka.net/applockergpo ​ #Permissions Weakness in Non-Default Directories A vulnerability exists when enterprise software has been installed on the root of C:\. The default permissions allow a user to replace approved software binaries with malicious binaries. ​ Further information can be found @ https://www.tenaka.net/unquotedpaths ​ #Files that are Writeable System files that allow users to write can be swapped out for malicious software binaries. Further information can be found @ https://www.tenaka.net/unquotedpaths #Firewalls Firewalls should always block inbound and exceptions should be to a named IP and Port. Further information can be found @ https://www.tenaka.net/whyhbfirewallsneeded

Creating a simple web report with PowerShell doesn't need to be a chore, there are limitations and it's definitely not a proper HTML editor. It doesn't mean the output should look shoddy. Like many, I'm using PowerShell to analyse Windows and display the results. The screen grab below is a section of a report I'm currently working on and soon to be published. The script is a comprehensive vulnerability assessment written entirely in PowerShell and made to look pretty without trawling through copious amounts of log outputs. This blog will cover the basics of taking PowerShell objects from various sources and creating HTLM output. It's not difficult, just fiddley, a couple of different techniques to successfully convert PowerShell to HTML may be required. Before everyone gets critical regarding the script formatting, some are due to how ConvertTo-HTML expects the data, most are to help those that aren’t familiar with scripting. There is a conscious decision not to use aliases or abbreviations and where possible to create variables. #Set Output Location Variables Nothing challenging here, creates a working directory, and sets the variable for the report output. Tests the existence of the path and if doesn’t exist creates the directory structure. $RootPath = "C:\Report" $OutFunc = "SystemReport" $tpSec10 = Test-Path "$RootPath \$OutFunc\" if ($tpSec10 -eq $false) { New-Item -Path "$RootPath \$OutFunc\" -ItemType Directory -Force } $working = "$RootPath \$OutFunc\" $Report = "$RootPath \$OutFunc\"+ "$OutFunc.html" #HTML to Text Keep it simple, create a variable and add some text. This is the one that ought to be straightforward and ended up being a bit of a pain. The conversion to HTML ended up producing garbage. Google gave some interesting solutions…. The fix I discovered turned out to be super simple. The fragment needs to be set as a ‘Table’ and not a ‘List’. Doh….. $Intro = "The results in this report are a guide and not a guarantee that the tested system is not without further defects or vulnerabilities." #Simple WMI This is a report about Windows, had better collect some wmi attributes. There are 2 methods, dump the attributes into a variable and process them later. Or create a variable for each required attribute and hashtable the data, the latter is a lot of effort. $hn = Get-CimInstance -ClassName win32_computersystem $os = Get-CimInstance -ClassName win32_operatingsystem $bios = Get-CimInstance -ClassName win32_bios $cpu = Get-CimInstance -ClassName win32_processor #Foreach and New-Object. Now life starts to get interesting. The date format needs updating from “23/11/2021 00:00:00” to “23/11/2021” to maintain the formatting a ‘foreach’ is required to strip out the additional characters per line, then added to an array. Under normal circumstances, the red code snippet would suffice. Foreach ($hfitem in $getHF) { $hfid = $hfitem.hotfixid $hfdate = ($hfitem.installedon).ToShortDateString() $hfurl = $hfitem.caption $newObjHF = $hfid, $hfdate,$hfurl $HotFix += $newObjHF } When dealing with HTML the correct method requires the use of ‘New-Object’ command. $HotFix=@() $getHF = Get-HotFix | Select-Object HotFixID,InstalledOn,Caption Foreach ($hfitem in $getHF) { $hfid = $hfitem.hotfixid $hfdate = $hfitem.installedon $hfurl = $hfitem.caption $newObjHF = New-Object psObject Add-Member -InputObject $newObjHF -Type NoteProperty -Name HotFixID -Value $hfid Add-Member -InputObject $newObjHF -Type NoteProperty -Name InstalledOn -Value ($hfdate).Date.ToString("dd-MM-yyyy") Add-Member -InputObject $newObjHF -Type NoteProperty -Name Caption -Value $hfurl $HotFix += $newObjHF } #Pulling Data from the Registry Registry keys require the ‘Get-ChildItem’ followed by ‘Get-ItemProperty’ to extract the individual settings from the Registry Hive. Each setting is then assigned to a variable. $getUnin = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\" $UninChild = $getUnin.Name.Replace("HKEY_LOCAL_MACHINE","HKLM:") $InstallApps =@() Foreach ( $uninItem in $UninChild) { $getUninItem = Get-ItemProperty $uninItem $UninDisN = $getUninItem.DisplayName -replace "$null","" $UninDisVer = $getUninItem.DisplayVersion -replace "$null","" $UninPub = $getUninItem.Publisher -replace "$null","" $UninDate = $getUninItem.InstallDate -replace "$null","" $newObjInstApps = New-Object -TypeName PSObject Add-Member -InputObject $newObjInstApps -Type NoteProperty -Name Publisher -Value $UninPub Add-Member -InputObject $newObjInstApps -Type NoteProperty -Name DisplayName -Value $UninDisN Add-Member -InputObject $newObjInstApps -Type NoteProperty -Name DisplayVersion -Value $UninDisVer Add-Member -InputObject $newObjInstApps -Type NoteProperty -Name InstallDate -Value $UninDate $InstallApps += $newObjInstApps } #Cascading Style Sheets (CSS) To apply a consistent style to each element we use a CSS containing text size, colour and font as well as spacing and background colours. Each style, for example 'h1' has a set of properties that applies to any number of elements tagged "variable or text". reducing repeat lines of code required, updating the CSS and all elements receive the change. CSS Tutorial (w3schools.com) is a good resource to learn and try out CSS. In the example below h1, h2 and h3 set different sized fonts and colours. $style = @"

There's a common theme running through many of the security articles on this site. Prevent lateral movement of hackers around the domain searching for escalation points to elevate to Domain Admins. Preventing escalation via cached or actively logged on privileged accounts can be accomplished with segregated tiers between Workstations, Servers and Domain Controllers. Implementing tiers does not prevent exploitation of system vulnerabilities and escalating via an RCE for example. Tier 0 - Domain Admins, CA's, plus any management service running agents on the DC's. Tier 1 - Member Servers. Tier 2 - Workstations. Segregation is achieved with the use of User Rights Assignments (URA) via Group Policy, additional admin accounts and AD groups. The initial concept is easy, don't allow any account access across the boundaries between Workstation, Server or DC. Workstation admin accounts are prevented from logging on to servers and DC's. Server admins or server service accounts are unable to login to a Workstation or DC. Domain Admins never log on to anything but DC's. The theory sounds easy until management agents are installed on DC's. There's the potential for the SCOM or SCCM\MECM admin to fall victim to an attack. The attacker is granted System on the DC's via the agent, despite the admin not being a Domain Admin. I recommend not installing management agents on DC's or CA's. One solution, as this is the real world, install the management applications with an installer account and delegate privileges to the relevant groups and triers, making sure not to cross the streams. Or create an additional tier for management servers with agents deployed to DC's. The downside of tiers is extra accounts. If you're the DA then 3, possibly 4 admin accounts per domain are required. There's no perfect solution or one size fits all, aim to separate the tiers but allow for flex in the solution. The only hard and fast rule is 'never allow any server admin or DA to login to workstations.' Before starting Domain Administrator privileges are required. First create the AD Groups for denying Domain Controller, Server and Workstation logon. Open 'AD Users and Computers' and create the following AD Groups: RA_Domain Controller_DenyLogon RA_Server_DenyLogon RA_Workstation_DenyLogon Create the following accounts: tenaka_wnp (workstation administrator) tenaka_snp (server administrator) tenaka_dnp (domain admin) Going to assume you're happy creating Restrictive Groups in Group Policy and assigning them to OU's. Create the following AD Groups, assigning them to the relevant OU. PR_Workstation_Admins PR_Server_Admins Add tenaka_wnp to PR_Workstation_Admins Add tenaka_snp to PR_Server_Admin Add tenaka_dnp directly to Domain Admins, don't nest groups within Domain Admins. RA_ designates User Rights Assignment. PR_ designates PRivileged account. This is part of a naming convention used within this Domain. Open RA_Workstation_DenyLogon group. Add Domain Admins, all server service accounts and PR_Server_Admin. Create a new GPO for the Workstations OU. Update the following User Rights Assignments with RA_Workstations_DenyLogon. Deny log on as a batch Deny log on as a service Deny log on locally Deny log on through Remote Desktop Services Open the RA_Server_DenyLogon group Add Domain Admins, PR_Workstation_Admin and service accounts not deployed to a server. Svc_scom_mon_ADMP performs synthetic transactions testing the performance of internal websites and DNS lookups. Create a new GPO for the Servers OU Update the following User Rights Assignments with RA_Server_DenyLogon Deny log on as a batch Deny log on as a service Deny log on locally Deny log on through Remote Desktop Services Open the RA_Domain Controller_DenyLogon group. Add PR_Workstation_Admin, PR_Server_Admin and service accounts not used on DC's. Create a new GPO for the Domain Controller container. Update the following User Rights Assignments with RA_Domain Controller_DenyLogon Deny log on as a batch Deny log on as a service Deny log on locally Deny log on through Remote Desktop Services Run gpupdate /force on a workstation, server and domain controller to apply the changes, a restart may be necessary. All that remains is testing. Attempt to login to a workstation with tenaka_wnp, tenaka_snp, tenaka_dnp, the only account that will successfully login is tenaka_wnp. Attempt to logon to the server with tenaka_wnp, tenaka_snp, tenaka_dnp, the only account that will successfully logon is tenaka_snp Attempt to logon to a Domain Controller with tenaka_wnp, tenaka_snp, tenaka_dnp, the only account that will successfully logon is tenaka_dnp

I've always wondered if other IT Professionals take their work home??? I don't take work home, I take my hobby to work....There is a serious side to this approach, it allows freedom to explore Microsoft and Linux products without constraints and it provides insights into the tech articles vs reality without the constraints of deliverables. The following describes my main home environment. Hardware: Intel NUC's - i7's with 32Gb RAM, 1Tb SSD and 4TB 2.5" SSD Intel NUC Skull Canyon 32Gb RAM, 1Tb SSD VNAND Dell XPS 15 ASUS Zenbook 580 ASUS Zenbook 490 ASUS Zenbook 301LA Synology Nas 4 Bay 8Tb Usable Synology Nas 1 bay 4Tb Usable (Selective Backup) Zyxel USG60W 4 * Odroids UX4 (2 * load-balanced PI Holes) Raspberry Pi 4 Raspberry Pi Zero * 2 Odroid C4 (RAT) Dual Wifi and RJ45 - Kali Rat Various 1Gb switches HP 476MFD Software: Microsoft Action Pack - £470 per year Linux and Pi distros Main infrastructure, doesn't include vm's that are only spun up for testing: NUC1 (HYP1) DC19-1 DC19-2 SCCM-1 NUC2 (HYP2) OPS-1 MDT-1 DC19-3 The diagram below details the internal DNS setup, there's a method to this madness. The 2 Synology NAS's act as DNS proxies performing all-recursive queries, protecting the DC's from connecting directly to the Internet. The Pi Holes are load balanced and placed between the member servers, clients and DC's, enabling hostname resolution in the PiHole logs. Whilst filtering all the nasties away from the clients and servers. NUC's - The powerful and relatively cheap to run Intel NUC's are host servers. Don't criticise they're Hyper-V, there are benefits, more secure than alternatives....bare with me... don't rage, they receive their patches automatically every month from Microsoft. I specialise in Microsoft OS security and am more confident in securing Windows. Hyper-V finally allows me flexibility with migrating vm's across all the NUC's, Laptops and Skull Canyon. Shares and DFS - NUC1 hosts the main bulk of the user shares with shares for Home, Groups and Media, plus a Software Library going all the way back to Windows NT 4 sp3. The shares are presented to the user with GPO preferences. DFS allows moving the data to a new host without the users (my family) being aware. DC's - Windows 2019 Server makes up the Domain Controllers, each Hyper-V host has a DC. The 3rd DC doesn't run any FSMO roles and it's the first to be replaced with a new OS release. Build a new DC alongside and demote the old. No in-place upgrades help keep the DC's clean. SCCM\MECM - Yes I've deployed an enterprise management solution at home. Yes, it does deploy Windows clients and applications and there is the odd, quite a lot, to be honest, compliance rules. Yes, it can deploy Windows Updates, just doesn't any longer. Until a couple of years ago, my main job was as an SCCM engineer. SCOM - Monitors performance of all servers and various synthetic transactions eg the Internet from client to Google. Custom event rules alert for activities that shouldn't happen across all DC's, servers and clients. MDT - Creating gold images of course.... Backups - 2-way replication exists between the Windows Shares and Synology-1. Android phones automatically upload new photos and videos to the NAS, and then replicated them to the Windows Media share. Equally any new content added to the Windows shares is backed up to the NAS. Synology-2 provides a sort of off-site backup, being away from the main house. Clients - Windows 10 clients run the very latest release and are members of the Domain. I don't allow any non-domain joined Windows on the main network. Android is Ok, not Windows and never the head in the sand crapple. Security - It's extensive, from firewalls to GPO, Applocker, Device Guard, IPSec and role separation with AD. Clearly, I'm not going to give too much away, everything is turned up to level 10. That's a very quick overview of the home network.

For the past 5 or 6 years local Applocker policies have been created with Powershell scripts and since Jan 2021 (ish) importing and merging .xml files produced the following error with the following command: Set-AppLockerPolicy -XmlPolicy "C:\Secure10\Applocker\Enforce.xml" -Merge Set-AppLockerPolicy : The specified rule collection already exists in the policy. At line:1 char:1 + Set-AppLockerPolicy -XmlPolicy "C:\Secure10\Applocker\Enforce.xml" -M ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Set-AppLockerPolicy], RuleCollectionAlreadyExistsException + FullyQualifiedErrorId : Microsoft.Security.ApplicationId.PolicyManagement.PolicyModel.RuleCollectionAlreadyExistsException,Microsoft.Security.App licationId.PolicyManagement.Cmdlets.SetAppLockerPolicyCmdlet Fresh installation of Windows 10, deploy the PS script and import local policies without issue. Merge can be executed multiple times for all the xml files that PowerShell has generated. Same client, commands and policies but updated and merge won't work.... This issue is one for Microsoft to resolve and once an answer is forthcoming I'll post it. Has anyone else experienced the same problem?

Apparently, the wife reckons it does, but she could be having a dig..... This is a bit of fun, nothing scientific, does the size of the wifi antenna matter? The laptop is the Asus Zenbook 301LA with an internal wifi adapter vs the Alfa AWUS036AC USB wifi adapter The tests will comprise of running 'nmcli dev wifi' for the internal adapter and Alfa with 18cm and 36cm antenna's. Internal - top-rated signal strength is 65 and 17 SSID's Alfa 18cm Antenna - top-rated signal strength 3 * 100 and 24 SSID's Alfa 36cm Antenna - top-rated signal strength 2 * 100 and 26 SSID's. The Alfa ran rampant over the internal adapter with both increased signal strength and range (visible AP's). Surprising the Alfa 18cm antenna beat the 36cm antenna for top signal strength. However, 14 SSID's were above 51 for the 36 cm antenna whereas only 8 are listed for the 18cm antenna. Interestingly the internal adapter showed a connection speed of 115Mbs and the Alfa 144Mbs on the network settings. The wife is correct, size does matter, she ain't going to let this go. Although the 18cm antenna holds the outright top signal strength the 36cm antenna has further reach and lists more SSID's. The internal wifi adapter is rubbish, as I said this is not scientific.... It's definitely advantageous to use a dedicated external USB wifi adapter, speed and range are improved. Would I sit in a coffee shop with that monstrosity sticking out of my laptop when I'm trying to look inconspicuous......

There's lot on the web regarding passwords and what they should consist of. There are plenty of sites that also validate the strength of a would-be password. But do those sites make useful suggestions??? Let's find out. But first what makes a stronger better password? Clearly, the longer and the more types of characters used the better. However creating a password from a word and substituting letters for numbers is not advisable, password cracking tools cater for this behaviour and adding numbers to the end of a word. Password, Pa$$word, P455word, Password1234 are some truly awful examples of what's bad. The following table shows the top sites from google search results. So I decided to test those sites. Passwords of varying complexity were entered and the results are below. The colour coding depicts how well the site did with a given password. Red is bad, Yellow is okish and Green is good. As you can see some sites believe that 'Password1234' will take 10,000 years to crack. Of the sites tested only 'https://www.my1login.com' provided realistic results for known passwords. I'm not sure of the validity of 'sokv3sHMqdCgUB' taking 27 trillion years to crack, it's based on A to Z upper and lower case characters and numbers. 'https://password.kaspersky.com/' rates the password and validates it against known password lists. Interestingly Kaspersky rated 'sokv3sHMqdCgUB' higher than ''u%L~C3|u^@ LT'. We know not to trust sites to validate the strength of passwords and have an idea of what is acceptable, and what's a bad password. So the advice is mixed and managing the type and number of complex passwords required is a massive nightmare. My suggestion is to delegate the task to a program designed to generate passwords, personally, I use Keepass all my passwords look something like the following 'L$e(`}0}*MmhtKm(WBrY' or '0iJqhzxlMv81mU6ARnVf', both are 20 characters. Some sites don't support the additional special characters and an alternative A to Z and Number password is needed. Simple, right!!! Not really, Kaspersky collects password lists and by the looks of it, many thousands of password lists. Many of those lists will be from sites and companies that have been hacked and their passwords uploaded to the Internet. Visit 'https://www.avast.com/hackcheck', it's the same as 'https://haveibeenpwned.com/' but better, no signing up and Avast delivered an email with the sites and associated passwords. It's never simple and there's a 'but'. Companies that have been hacked try and hide the fact or simply don't know for extended periods. Your password or encrypted password could be out in the wilds and you may never know, undermining the long complex Keepass passwords. What to do.... 2 Factor Authentication..... what the......Don't panic it's not that bad..... If your Android user downloads 'Google Authenticator'. For any site that provides email, financial or social media enable 2FA. When you log on the password is entered and a rotating 6-digit pin from the phone is entered. If your password is compromised the hacker won't have the second part of the authentication to logon. Hopefully, an alert will be sent to your email address informing you of an unsuccessful login attempt, providing time to change the password. In these connected times, it's important to secure your online presence as much as you secure your personal possessions with locks on the doors. Of course, burying your head can be an alternative plan, however, I belong to the tin hat brigade and tend to secure everything to the point it stops being useful ;)

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

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.

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/

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.

What do you do with your local administrator passwords? Spreadsheet on a share or are the passwords the same, the admin account could even be disabled??? LAPS from Microsoft maybe the answer. Its a small program with some GPO settings. LAPS randomly sets the local administrator password for clients and servers across the estate. Firstly download LAPS from the Microsoft site Copy the file to the Domain Controller and ensure that the account you are logged on has 'Schema Admin'. Install only the Management Tools. As its a DC its optional whether to install the 'Fat Client UI', Schema updates should always be performed on a DC directly. Open Powershell and run the following command after seeking approval. Update-AdmPwdSchema SELF will need updating on the OU's for your workstations and servers. Add SELF as the Security Principal. Select 'Write ms-Mcs-AdmPwd Now change the GPO settings on the OU's. The default is 14 characters but I would go higher and set above 20. Install LAPS on a client and select only the AdmPwd GPO Extension On the Domain Controller open the LAPS UI and search and Set a client. Once the password has reset open the properties of the client and check the ms-Mcs-AdmPwd for the new password. Now every 30 days the local Admin password will be automatically updated and unique. Deploy the client with ConfigMgr to remaining estate. By default Domain Admin have access to read the password attribute and this can be delegated to a Security Group. AND.....this is the warning.....Any delegated privileges that allow delegated Computer management and the 'Extended Attributes' can also read the 'ms-MCS-AdmPwd'.