As a Microsoft engineer, deploying Visual Studio Code on Rocky Linux using Ansible highlights the intersection of enterprise-grade tools and open-source flexibility. While much of my experience revolves around the Microsoft ecosystem, there’s a certain satisfaction in utilizing the power of YAML and automation to streamline deployment processes. Ansible, a robust open-source automation tool, allows engineers to efficiently manage configurations, resolve dependencies, and ensure consistent deployments. This guide outlines the steps and considerations for deploying Visual Studio Code on a Rocky Linux system using Ansible, demonstrating how to combine open-source tools with Microsoft's developer resources for maximum efficiency. So why Rocky Linux? Why Ansible? Because, in the spirit of open source, we go where the community goes. And because, as much as I love PowerShell, sometimes you just want to let Linux do its thing. Let’s dive in and show the world that even a Microsoft engineer can deploy Microsoft software with an open-source tool on a Linux distro. Spoiler alert: It’s actually kind of awesome. Pre-Requisites Steps Before diving into Ansible, we have set up three Rocky Linux virtual machines, each configured with 2 CPUs and 4GB of RAM. Rocky Linux Nodes rocky01 = 192.168.0.28 - Ansible Controller rocky02 = 192.168.0.38 - Dev Node 01 rocky03 = 192.168.0.39 - Dev Node 02 Create an Admin User During the setup, each node was configured with a user account named 'user' that has administrator privileges. If root was used instead, create an account with the following configuration: sudo root sudo adduser user sudo passwd user sudo usermod -aG wheel user Install SSH on Dev Nodes (02-03) SSH to each of the Dev nodes ssh user@192.168.0.38 ssh user@192.168.0.39 Install openssh-server sudo dnf install openssh-server Create a Public\Private Key on the Ansible Controller Generate an SSH key using the user account. ssh-keygen -t ed25519 -C "ansible controller" Either provide a file name or use the default option. If you choose to specify a file name, ensure you include the full path. For best practice, enter a password. However, pressing Enter without typing anything will leave the password blank. ssh-keygen: This is the command used to generate, manage, and convert SSH keys. -t ed25519: Specifies the type of key to create. ed25519 is an elliptic-curve signature algorithm that provides high security with relatively short keys. It is preferred for its performance and security over older algorithms like rsa or dsa. -C "ansible controller": Adds a comment to the key. This comment helps identify the key later, especially when managing multiple keys. In this case, the comment is "ansible controller", which likely indicates that the key will be used for an Ansible control node. List the contents of the .ssh directory. The .pub file contains the public key, which is to be shared with other nodes. ls -la .ssh Copy the Public Key to the Dev Nodes Use the ssh-copy-id command to copy the public SSH key to the Dev nodes, enabling passwordless authentication. This command appends the public key to the ~/.ssh/authorized_keys file on the target node, ensuring secure access. For example: This process requires the target node's password for the first connection. Afterward, the SSH key allows secure, passwordless logins. ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.0.38 ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.0.39 Test the connection to each Dev node. ssh -i ~/.ssh/id_ed25519 user@192.168.0.38 ssh -i ~/.ssh/id_ed25519 user@192.168.0.39 Install Ansible on the Controller Node Set up Ansible on the Ansible Controller node by executing the following commands; sudo dnf updates sudo dnf install epel-release sudo dnf install ansible Copy Playbook from Github Clone the GitHub repository and move it to /home/user/ansible-vsc. git clone https://github.com/Tenaka/ansible_linux_vcs.git mkdir ansible-vcs mv ansible_linux_vcs/* ~/ansible-vcs cd ansible-vsc Keep in mind that ~ refers to the home directory in Linux. tree A Quick Review of the Playbook Some amendments to the inventory.txt file is probably needed, so I'm using nano as the text editor and steering clear of vi—there's only so much this MS Engineer is willing to embrace. Ansible.cfg defines the settings for this ansible playbook: inventory = Specifies the inventory file (inventory.txt) that contains the list of hosts Ansible will manage. private_key_file = ~Indicates the path to the private SSH key (~/.ssh/ided25519) used for authenticating to remote hosts. ~/ansible-vsc/ansible.cfg [defaults] inventory = inventory.txt private_key_file = ~/.ssh/ided25519 ~/ansible-vsc/inventory.txt [all] 192.168.0.28 192.168.0.38 192.168.0.39 [visualstudio] 192.168.0.38 192.168.0.39 ~/ansible-vsc/visualcode.yml --- - hosts: all become: true roles: - baseline - hosts: visualstudio become: true roles: - visualstudio ~/ansible-vsc/roles/visualstudio/tasks/main.yml - name: Add Microsoft GPG key rpm_key: state: present key: https://packages.microsoft.com/keys/microsoft.asc - name: Add Visual Studio Code repository yum_repository: name: vscode description: "Visual Studio Code" baseurl: https://packages.microsoft.com/yumrepos/vscode enabled: yes gpgcheck: yes gpgkey: https://packages.microsoft.com/keys/microsoft.asc - name: Install Visual Studio Code yum: name: code state: latest # Dont run as root and install extensions - name: Install desired VS Code extensions become: false shell: "code --install-extension {{ item }} --force" loop: - redhat.ansible - redhat.vscode-yaml register: vscode_extensions changed_when: "'already installed' not in vscode_extensions.stdout" - name: Display installed extensions debug: msg: "Installed extensions: {{ vscode_extensions.results | map(attribute='item') | list }}" While VSC is installed using sudo, installing extensions with elevated privileges does cause issues. Therefore, become is set to false. Deployment of Visual Studio Code Make sure to run the playbook from the ~/ansible-vsc directory. The command ansible-playbook --ask-become-pass visualcode.yml runs the Ansible playbook visualcode.yml with the following options: --ask-become-pass: Prompts you to enter a password for elevated (sudo) privileges on the target hosts. visualcode.yml: Specifies the playbook file to be executed. ansible-playbook --ask-become-pass visualcode.yml Enter the password at the prompt and sit back whilst ansible does all the work. In Ansible playbook output, 192.168.0.38 had previously been successful in deploying VSC during testing: changed: Indicates that a task made modifications to the target system. ok: This means that the task has successfully completed without making any changes. This often happens when the system is already in the desired state, such as when a package is already installed or a configuration file is already correct. Of course, these Linux boxes have a GUI installed—I'm an MS Engineer, and it's required for VSC. So login to each of the Dev nodes and launch VSC. After rolling up my sleeves and diving headfirst into the untamed wilderness of Linux, this Microsoft engineer emerged with calloused hands, and a newfound love for ansible. Sure, there were battles with YAML, was that 3 or 4 spaces, but every “PLAY RECAP: SUCCESS" felt like a badge of honor. And while I still instinctively reach for the Reboot button at every minor annoyance, I now pause a second or two to consider if the reboot is the correct course of action. Of course it is, it's the only action that works.

EventID 40960 LSA (LsaSrv) The Security System detected an authentication error for the server cifs/DomainController. The failure code from authentication protocol NTLM was "The authentication failed since NTLM was blocked (0xc00004189)". After upgrading a domain client from Windows 11 23H2 to 24H2, I encountered an issue logging in with a smartcard. The login itself completes successfully, but once you're in, none of the domain mapped file shares are accessible. Instead, you're repeatedly prompted for the smartcard PIN, and authentication continues to fail. Interestingly, logging in with a regular username and password works without any problems—domain shares connect as expected and everything functions normally. The error recorded in the Security event log points to a failure in CIFS (SMB) authentication, specifically due to NTLM being blocked or unavailable. EventID 40960 LSA (LsaSrv) The Security System detected an authentication error for the server cifs/DomainController. The failure code from authentication protocol NTLM was "The authentication failed since NTLM was blocked (0xc00004189)". The environment is a Windows Server 2019 domain where NTLM is still permitted as a fullback when Kerberos fails. The clients and servers are a mix of Windows 11, Server 2019, and Server 2022. Users currently have the option to log in using either their YubiKey smartcards or traditional passwords. However, the plan is to transition fully to smartcard PIN-based logins—eliminating password-based authentication entirely within the next month. After a little research aka Google, and coming up empty, I didn’t find a definitive answer—but I did come across a few mentions that pointed toward the Security Option “Network security: Configure encryption types allowed for Kerberos.” I checked the setting, and sure enough, it was already configured globally to allow AES128_HMAC and AES256_HMAC_SHA1, so that didn’t appear to be the root cause. I’d love to say the fix was the result of some deep technical insight or a brilliant deduction, connecting all the dots. This was a shot-in-the-dark, coffee-fueled “I’ve seen enough weird Windows behavior to get a sense of déjà vu”. No documentation. No forum thread or Google results. And I hadn’t planned on doing anything more complex than turning on the Xbox and zoning out for a bit. I definitely wasn’t in the mood to wade through GPO settings or start faffing with klist and whatever other diagnostics I'd normally drag out for this kind of thing. So instead, I just opened up my user account settings, ticked the two checkboxes for “Kerberos AES encryption,” sighed, and hit OK—fully expecting nothing. And naturally… it worked. I logged with a smartcard and pin all the mapped network drives were present and accessible, then repeated the exercise with other accounts that had failed. The system was back and behaving itself. I really ought to thank Microsoft for their newfound consistency—consistently giving me fresh new material to blog about. It’s almost heartwarming, really. Takes me right back to the glory days of Windows NT 4, when every new Service Pack was less of an update and more of a creative new way to keep me gainfully employed.

Back in December 24, I put together an article on installing and configuring a Raspberry Pi and Pi-Hole. It’s over here if you’re curious: https://www.tenaka.net/post/pi-hole-ad-blocker-setup . The initial deployment was a straightforward dual-Pi setup on a flat 192.168.0.0/24 network. It was simple to manage and, at the time, I was content relying on the existing Windows security and Firewall controls to protect the domain-joined systems. However, as the network footprint expanded, with an increasing number of Internet facing devices and other less-trustworthy endpoints, "stuff" made East of where I live, the risk profile changed significantly. Relying on a flat topology became untenable, and the lack of segmentation started to feel like an open invitation for lateral movement. It was clear the convenience trade-off had reached its limit. So I decided to implement a vLAN or 2, let me provide a very basic explanation of vLANs. VLAN (Virtual LAN) A VLAN (Virtual LAN) is a logical segmentation of a network at Layer 2 that allows you to group devices as if they were on separate physical networks, even if they share the same switch or cable. By isolating traffic between VLANs, the broadcast domains are reduced and lateral movement is limited, improving both performance and security. Communication between VLANs requires routing, typically through a Layer 3 switch and, in my case, a new PFSense firewall, giving control over the ports and IP's that can communicate. That covers the why , but not the how , specifically how I got VLAN tagging working on the Raspberry Pis. On Windows, it’s pretty much a checkbox and you're done. On Raspbian ? Yeah... not quite that simple. Before bashing the keyboard, PiHole is at version 6.0.6, installed on Raspberry Pi 4's with 4Gb RAM, with Raspbian being at version 6.6 plus all the latest updates. IP addresses are DHCP assigned and then reserved. Install VLAN Package Install the latest updates and then vlan package. sudo apt update sudo apt install vlan Load the 8021q kernel module, which is essential for enabling VLAN tagging on network interfaces. sudo modprobe 8021q echo "8021q" | sudo tee -a /etc/modules Define how VLANs are created and configured. sudo nano /etc/systemd/network/25-vlan.network [Match] Name=eth0.VLAN_ID [Network] DHCP=yes This file instructs systemd-networkd how to create and manage the VLAN interface sudo nano /etc/systemd/network/25-vlan.netdev [NetDev] Name=eth0.VLAN_ID Kind=vlan [VLAN] Id=VLAN_ID Update the VLAN tagging on the network switch that the Pi's are plugged into. Restart the network interface. sudo systemctl restart networking sudo systemctl status networking Confirm the IP has updated from 192.168.0.70 to 192.168.10.70. ip addr show Finally, I updated the Domain Controller's DNS Forwarders to point to the new addresses.

In this blog, we'll examine how threat actors—often referred to as hackers—can escalate privileges when weak file, directory, or registry permissions are present. Many programs disable directory inheritance or assign excessive permissions to user accounts, leading to vulnerabilities. Finding these misconfigurations can be challenging, as it involves reviewing extensive file, directory, and registry hive permissions that are often overlooked. Fortunately, I have a few scripts that help detect and report these vulnerabilities and can also reset permissions to their secure defaults. But first, let’s dive into the problem at hand... The Risks Here's a revised version of the text with your requested additions: "Improperly configured permissions for files, directories, and registry entries often create significant vulnerabilities that threat actors can exploit to escalate privileges or break out of restricted environments. When permissions are inadequately set, threat actors can gain access to or modify sensitive files, ultimately providing a pathway for unauthorized actions. Weak permissions enable unauthorized users to write and execute programs in specific directories or modify registry application paths, allowing them to redirect these paths to malicious locations. This redirection enables threat actors to inject and run their own code, giving them access to sensitive information or control over existing applications and files. Beyond simply executing programs, insecure directory permissions also allow unauthorized modification of file permissions. This level of access can be used to alter or delete important files or to introduce new files containing harmful code. Finally, these weak permissions open doors for attackers to leverage vulnerabilities within the operating system or its applications, allowing further access to the system. Additionally, unquoted paths and services with insufficient security configurations provide additional avenues for exploitation, allowing attackers to execute unauthorized commands and compromise system integrity." What to do.... Manually validating permissions across the operating system can be a slow and tedious process. After discovering some critical permission issues and recognizing the importance of thorough validation, I began developing a script for automated validation and pentesting. This script is available for download on GitHub, with all relevant links provided at the bottom of the page. The Scripts The Security Report Support Page Fix for Weak Permissions Fix Unquoted Paths

Understanding Windows 11, TPMs, PCRs, and Security Features Windows 11 requires Trusted Platform Module (TPM) 2.0 as part of its foundation for enhanced security, alongside features like Secure Boot, BitLocker, and Virtualization-Based Security (VBS). With these tools, Microsoft aims to shield devices from evolving threats in an increasingly hostile digital landscape. This article takes a closer look at these features and highlights their limitations, particularly in the context of remote attacks. Trusted Platform Module (TPM): The Basics A Trusted Platform Module (TPM) is a specialized chip designed to enhance security by providing cryptographic operations, safeguarding sensitive data, and ensuring system integrity. It can: Generate, store, and manage cryptographic keys. Validate the integrity of the boot process using Platform Configuration Registers (PCRs). Support security features like BitLocker and VBS. Types of TPM Discrete TPM: A dedicated hardware chip soldered to the motherboard. Firmware TPM (fTPM): Built into the CPU and implemented via firmware. Checking TPM Status Windows Security App: Go to Settings > Privacy & Security > Windows Security, then navigate to Device Security > Security Processor. TPM Management Console: Open the Run dialog, type tpm.msc , and press Enter to check the status and specification version. Command Line: Run tpmtool getdeviceinformation  to retrieve detailed TPM data, TPM Version: The specification version of the TPM (e.g., 2.0). Manufacturer Information: The manufacturer ID and version of the TPM chip. Supported Algorithms: Lists cryptographic algorithms supported by the TPM (e.g., RSA, SHA-256, etc.). PCR Banks: The hash algorithms used for Platform Configuration Registers (PCRs), such as SHA-1 or SHA-256. PCR Information: Indicates which PCRs are active and their supported configurations. TPM Status: The current operational state of the TPM, such as whether it's enabled, activated, or ready for use. PowerShell Cmdlets: Get-Tpm: Displays TPM status and version. Platform Configuration Registers (PCRs): Ensuring Boot Integrity PCRs in the TPM store hashed measurements of the System state during boot, providing a cryptographic log of boot-time events. They ensure integrity by providing a cryptographic record of boot-time events Uses of PCRs Secure Boot: Validates the bootloader, ensuring only trusted code is executed. BitLocker: Uses PCR values to confirm system integrity. Mismatched values (e.g., from tampering) trigger recovery mode. Commonly Used PCRs PCR 0: Measurements from the BIOS, firmware, and Core Root of Trust for Measurement (CRTM). PCR 2: Reflects UEFI Secure Boot state. PCR 4: Tracks bootloader integrity. PCR 7: Represents Secure Boot configuration. What is Secure Boot? Secure Boot, a UEFI feature that ensures only signed and trusted bootloaders are executed during system startup. The TPM strengthens this process by securely measuring and storing key boot components' hashes in its Platform Configuration Registers (PCRs). These measurements create a tamper-proof record of the boot sequence. How Secure Boot Works: Digital Signatures: Each component in the boot chain (e.g., firmware, bootloader) must have a valid digital signature. Key Hierarchies: Platform Key (PK): Authorizes changes to Secure Boot settings. Key Exchange Key (KEK): Manages authorized signatures. Allowed and Forbidden Lists: Specify trusted and untrusted binaries. Secure Boot and PCRs: PCR 7 reflects the Secure Boot state. Tampering with Secure Boot settings results in a different PCR value. Checking Secure Boot Status: Open the System Information tool (msinfo32). Look for Secure Boot State in the report. What is BitLocker? BitLocker is a full-disk encryption feature that leverages TPM to secure data. It ensures that data remains inaccessible if the system is tampered with or the drive is removed. How BitLocker Uses TPM: Stores encryption keys securely in TPM. Validates PCR values during boot. If the values match the expected measurements, the drive is unlocked. Configuring BitLocker: Open Explorer, navigate to C: Right click on C: and select 'Manage Bitlocker. Turn on Bitlocker and follow the prompts. What is Virtualization-Based Security (VBS) and HVCI? Virtualization-Based Security (VBS) uses hardware virtualization to create isolated memory regions for security-critical operations, enhancing system security. VBS Features: Hypervisor-Enforced Code Integrity (HVCI): Ensures only signed and verified drivers and binaries are executed. Relies on TPM for key storage and Secure Boot for integrity validation. Credential Guard: Protects Domain user credentials by isolating LSASS (Local Security Authority Subsystem Service) processes. Enabling VBS: Check hardware support: Virtualization support in BIOS/UEFI. Run msinfo32 and look for "Hyper-V Requirements." Enable VBS: Open Windows Security > Device Security > Core Isolation. Enable Memory Integrity. Verifying VBS Status: Run msinfo32 . Look for Virtualization-Based Security in the report. What These Features Don’t Protect While these tools provide strong defenses against physical tampering, they fall short against remote threats: Credential Theft - VBS's Credential Guard protects domain credentials but doesn’t secure local account credentials, which can be dumped from memory. Additionally, techniques like pass-the-hash allow attackers to use stolen hashes without decryption. Application Exploits - TPM protections don’t block malware that exploits software vulnerabilities. Attackers can bypass these defenses by targeting unpatched applications. Hardware-Level Attacks - Physical attacks on the Low Pin Count (LPC) bus could extract BitLocker keys if no PIN is used. Network-Based Attacks - Features like Secure Boot and TPM don’t address phishing, network infiltration, or lateral movement. Building a Comprehensive Security Strategy To address these gaps, organizations should bolster TPM-based features with additional measures: Application Control - Tools like Windows Defender Application Control (WDAC) enforce strict policies, blocking unauthorized applications and malware. Regular Patching - Keeping systems and applications up-to-date mitigates risks from known vulnerabilities. Multifactor Authentication (MFA) - Adds a layer of protection against credential theft and unauthorized access. Endpoint Detection and Response (EDR) - Monitors for suspicious activity and stops advanced attacks. The Takeaway Windows 11’s TPM-centric security features excel at defending against physical attacks, but they can’t stop remote exploits, credential theft, or network-based threats on their own. Think of them as a sturdy lock—effective at preventing break-ins, but not enough if attackers exploit the open Window. A layered security approach is essential to stay ahead of sophisticated threats.

In my previous blog , I explored how Microsoft leverages the Trusted Platform Module (TPM) to secure Windows 11. In this article, we’re going to take a deeper dive into BitLocker. What is Bitlocker BitLocker is a full disk encryption feature integrated into Microsoft Windows, designed to safeguard the integrity and confidentiality of data. By encrypting the system drive, BitLocker ensures that unauthorized users cannot access sensitive information, even if they gain physical access to the hardware. A core part of BitLocker’s security lies in the use of the Trusted Platform Module (TPM), which securely stores cryptographic keys needed to decrypt the data. Key Concepts in BitLocker Encryption Before diving into the workings of the private key and AES or XTS-AES, let's briefly define some of the key components involved in BitLocker’s encryption process: Full Volume Encryption Key (FVEK): The FVEK is the primary encryption key used by BitLocker to encrypt and decrypt the entire volume (the disk or partition). It is a symmetric key, meaning the same key is used for both encryption and decryption. This key is essential for protecting the actual data stored on the drive. Trusted Platform Module (TPM): The TPM is a hardware chip embedded in most modern computers that provides secure storage for cryptographic keys and ensures that the system's boot process has not been tampered with. It is used in conjunction with BitLocker to protect the FVEK and to prevent unauthorized access to encrypted data. Password/PIN: A password or PIN is an optional but highly recommended security measure that adds an extra layer of authentication for unlocking the encrypted drive. This PIN/password is needed in addition to the TPM’s cryptographic keys to unlock the system during boot. Adding a PIN/password mitigates the Low Pin Count (LPC) Bus attack, Recovery Key: If the TPM or PIN is unavailable (for example, if the hardware is replaced), BitLocker provides a recovery key, which is a 48-digit alphanumeric key. This recovery key is essential for unlocking the encrypted drive in such cases. How BitLocker's Private Key Works The concept of a private key in BitLocker differs from that of traditional asymmetric encryption, where two keys (a private key and a public key) are used. BitLocker uses symmetric encryption for disk encryption, meaning it uses a single key (the Full Volume Encryption Key) for both encryption and decryption. However, BitLocker’s security is strengthened by using the TPM and other factors (such as a PIN or password) to protect access to the Full Volume Encryption Key (FVEK). The private key in this context is tied to the TPM and is crucial for managing access to the FVEK. Here’s how it all works in detail: Generation of the Full Volume Encryption Key (FVEK) When BitLocker is first enabled on a system, the FVEK is generated. This key is used to encrypt the entire disk or volume. However, to protect this key, it cannot be stored on the disk in plain text. Instead, it is stored securely using the Trusted Platform Module (TPM). TPM and the Protection of the Private Key The TPM plays a central role in BitLocker’s encryption system. It is a hardware-based security chip that is embedded in many modern systems to provide tamper-resistant storage for cryptographic keys. The TPM protects the FVEK by encrypting it with a TPM-specific key, which is known as the TPM’s Endorsement Key (EK). This key is unique to the TPM and cannot be extracted by unauthorized parties, even if the hard drive is removed from the system and connected to another computer. Here’s how the process works: Encrypting the FVEK: When BitLocker is enabled, the FVEK is encrypted with the TPM’s key (which is securely stored in the TPM chip itself). Storing the Encrypted FVEK: The encrypted version of the FVEK is stored in the system’s memory and on the disk. However, it cannot be decrypted without the TPM and proper authentication (such as a PIN, password, or recovery key). Unlocking the Encrypted FVEK: Upon system startup, the TPM checks the system’s configuration, including the integrity of the BIOS, bootloader, and other critical boot components. If any changes are detected (for example, due to a malware attack or hardware change), the TPM will refuse to release the FVEK, thus preventing unauthorized access to the encrypted data. Releasing the FVEK: If the TPM verifies that the system configuration is unchanged and trusted, it will decrypt the FVEK and pass it to the system. This is the moment when the encryption key becomes available to decrypt the data on the disk. At this point, the system can proceed with loading the operating system and allowing the user to interact with their data. AES-256 vs. XTS-AES-256: The Encryption Methods BitLocker can use different encryption algorithms, and understanding the difference between AES-128, AES-256, XTS-AES-128 and XTS-AES-256 helps in understanding how BitLocker protects your data. In the context of this article AES-128 and XTS-AES-128 will be ignored. Both AES-256 and XTS-AES-256 are symmetric encryption algorithms, meaning they use the same key for both encryption and decryption, but they differ in how they operate and the level of protection they offer. AES-256 AES (Advanced Encryption Standard) is a widely-used encryption standard that provides strong encryption capabilities. The "256" in AES-256 refers to the length of the key used in the encryption process: 256 bits. AES-256 works by encrypting the data in fixed-size blocks (128 bits) using a key that is 256 bits long. While AES-256 is secure and resistant to brute-force attacks, the challenge with traditional AES encryption lies in the potential vulnerabilities in how it handles block ciphers. Specifically, in the case of full-disk encryption, AES-256 does not account for the fact that some patterns might emerge within the plaintext data as it’s encrypted. This is where XTS-AES-256 comes in. XTS-AES-256 XTS-AES-256 (or XEX Tweakable Block Cipher with Ciphertext Stealing) is an enhanced version of AES-256 specifically designed for disk encryption. While it uses the same AES-256 algorithm, it introduces a second key and modifies the way the encryption is applied to improve security, especially against attacks on the underlying disk encryption. XTS-AES-256 employs tweaking as part of its encryption process. It uses a tweak value to change how each block is encrypted, preventing certain patterns or structures in the encrypted data from being exploited. This makes it significantly harder for attackers to perform certain types of cryptanalysis on the encrypted data, particularly in full-disk encryption scenarios. For BitLocker, XTS-AES-256 is the preferred encryption method because it is specifically designed for disk encryption and provides stronger protection in that context. Adding a PIN or Password In addition to the TPM’s encryption of the FVEK, BitLocker can also be configured to require an additional authentication factor, such as a PIN or password. This adds another layer of security, ensuring that the FVEK is not released even if the TPM is bypassed. Here's how the process works when a PIN is added: PIN Encryption: The PIN is combined with the TPM’s key and a unique public key to create a secure, trusted boot environment. This combination of the TPM’s key and the user-supplied PIN ensures that the encrypted disk remains inaccessible without both the physical TPM key and the correct PIN. Decryption of the FVEK: The TPM will release the encrypted FVEK only if the correct PIN is entered at boot. Without the correct PIN, even if an attacker has physical access to the machine, they cannot decrypt the FVEK and thus cannot access the data on the drive. How the LPC Bus Can Compromise the TPM The LPC bus operates as a communication channel between the TPM chip and the Southbridge, and indirectly to the Northbridge or CPU. Since this bus was not originally designed with modern security threats in mind, it lacks encryption or robust protection mechanisms. Enhancing Security with a PIN To mitigate the risk of LPC bus attacks, BitLocker allows the use of a PIN as an additional authentication factor. Here’s how it works: User Input Required: Before the decryption process begins, the user must enter a PIN. This adds an extra layer of security beyond the TPM’s PCR-based integrity checks. Secure Key Unsealing: The TPM uses the correct PIN to unlock the private key. Without the PIN, the private key remains sealed, even if an attacker has access to the LPC bus. Protection Against Physical Attacks: Since the PIN is not transmitted over the LPC bus, it cannot be intercepted. This makes it effective against attacks that exploit the LPC bus to extract the private key. Recovery Key In case the TPM is unable to release the FVEK (for instance, if hardware is changed or the TPM’s configuration is corrupted), BitLocker allows users to unlock the drive using a recovery key. This recovery key is typically a 48-digit alphanumeric code that can be used to manually unlock the drive when other authentication methods fail. The recovery key can be stored in various ways: Saved to a USB drive. Printed out and stored in a secure location. Stored in a Microsoft account or Active Directory for enterprise users. If the TPM does not release the FVEK during boot, the system will prompt the user to enter the recovery key, allowing access to the encrypted disk. Conclusion BitLocker, when used with the TPM and XTS-AES-256 encryption, provides a highly secure solution for protecting data at rest. The TPM ensures that the decryption key is securely stored and not easily extracted, while XTS-AES-256 improves the security of full-disk encryption by mitigating the risk of attacks that exploit patterns in the encrypted data. Incorporating a PIN into the BitLocker setup, along with TPM and XTS-AES-256 encryption, provides the highest integrity for securing sensitive data and protecting against a wide range of potential threats.

Introduction While PowerShell's Start-Transcript command is a common choice for logging script output, it has its shortcomings. It records console output (write-host) without providing structured log levels, detailed formatting, or robust error tracking. Logging in PowerShell scripts is often overlooked, I know I often overlook it for 'just a quick script', yet it plays a crucial role in confirming output and in this example the movement of family photos, there is nothing more important on my computer system than the decades of pictures and videos and can't afford for any to be deleted or lost. So logging is vitally important The script to organise files by Year and then by Month can be downloaded from ( here ). Reminder Before You Begin Before running this script on important files, make sure to test it first! While it works on during my testing and implementation, it's always best to double-check before making big changes. Overview This PowerShell script is designed to automate file organization within a specified directory. It performs two main functions: Detecting and moving duplicate files based on SHA256 hashes to a duplicates folder. Sorting remaining files into subdirectories organized by year and month based on their last modified date. Additionally, the script implements detailed logging to track its execution, errors, and actions taken during the process. Key Components of the Script 1. Parameters and Initialization The script accepts two parameters: $Data2SortPath: The main directory containing files to be organized. $duplicatesPath: A subdirectory where duplicate files will be moved. A log file is also created at the start with a timestamped filename: $LogFile = "$($Data2SortPath)\OrganizeFilesLog_$(Get-Date -Format 'yyyyMMdd_HHmmss').log" This ensures that each script run generates a new log file, preventing overwriting of previous logs. 2. Logging Functionality The script includes a custom logging function, Write-MoveLog, to standardize log messages: function Write-MoveLog { param ( [string]$Message, [string]$LogLevel = "INFO" ) $Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss" "$Timestamp [$LogLevel] $Message" | Out-File -FilePath $LogFile -Append } This function: Formats logs with a timestamp. Assigns severity levels (INFO, ERROR, WARNING). Writes logs to the designated log file. 3. Directory Validation and Setup Before processing files, the script checks whether the specified directory exists: if (-not (Test-Path -Path $Data2SortPath)) { Write-MoveLog "Error: The specified path '$Data2SortPath' does not exist." "ERROR" throw "The specified path does not exist." } If the directory does not exist, an error is logged, and execution is halted. Similarly, it ensures the duplicates folder exists or creates it: if (-not (Test-Path -Path $duplicatesPath)) { New-Item -Path $duplicatesPath -ItemType Directory -Force | Out-Null Write-MoveLog "Created duplicates folder at '$duplicatesPath'." "INFO" } 4. Retrieving Files for Processing The script gathers all files within the directory, excluding .log and .zip files: $gtFiles = Get-ChildItem -Path $Data2SortPath -Recurse -File | Where { $_.DirectoryName -notmatch "duplicates" -or $_.extension -notmatch ".log" -and $_.extension -notmatch ".zip" } This ensures only relevant files are processed. 5. Detecting and Handling Duplicates Each file’s SHA256 hash is computed to detect duplicates: $gtFileHash = (Get-FileHash -Algorithm SHA256 -Path $file.FullName).Hash If a duplicate is found, it is moved to the duplicates folder with a unique name to avoid overwriting: $duplicateName = Join-Path -Path $duplicatesPath -ChildPath $file.Name $counter = 1 while (Test-Path -Path $duplicateName) { $duplicateName = Join-Path $duplicatesPath -ChildPath ("{0}_{1}{2}" -f $file.BaseName, $counter, $file.Extension) $counter++ } Move-Item -Path $file.FullName -Destination $duplicateName Write-MoveLog "Duplicate detected: '$($file.FullName)' moved to '$duplicateName'." "INFO" 6. Organizing Files by Date For non-duplicate files, the script determines their last modified date and organizes them into Year/Month folders: $year = $file.LastWriteTime.Year $monthName = (Get-Culture).DateTimeFormat.GetMonthName($file.LastWriteTime.Month) $yearPath = Join-Path -Path $Data2SortPath -ChildPath $year $monthPath = Join-Path -Path $yearPath -ChildPath $monthName If these directories do not exist, they are created: if (-not (Test-Path -Path $yearPath)) { New-Item -ItemType Directory -Path $yearPath -Force | Out-Null Write-MoveLog "Created year folder at '$yearPath'." "INFO" } if (-not (Test-Path -Path $monthPath)) { New-Item -ItemType Directory -Path $monthPath -Force | Out-Null Write-MoveLog "Created month folder at '$monthPath'." "INFO" } Files are then moved to their respective folders: $destination = Join-Path -Path $monthPath -ChildPath $file.Name Move-Item -Path $file.FullName -Destination $destination -Verbose Write-MoveLog "File '$($file.FullName)' moved to '$destination'." "INFO" If a naming conflict occurs, the file is renamed and moved: if (Test-Path -Path "$destination\$file.Name") { $duplicateName = Join-Path $duplicatesPath -ChildPath ("{0}_{1}{2}" -f $file.BaseName, $counter, $file.Extension) $counter++ Move-Item -Path $file.FullName -Destination $duplicateName Write-MoveLog "File '$($file.FullName)' moved to '$duplicateName'." "WARNING" } 7. Error Handling and Final Logging Errors are caught and logged throughout the script: catch { Write-MoveLog "Failed to move file '$file.FullName': $_" "ERROR" continue } Finally, a message indicates the script's completion: Write-MoveLog "File organization complete. See details in the log file at '$LogFile'." "INFO" Write-Host "Processing complete. Logs are saved to '$LogFile'." Conclusion This PowerShell script makes sorting your files a breeze! It finds duplicates, organizes everything by date, and keeps a detailed log so you always know what’s happening. The built-in logging helps with troubleshooting, making it easy to track any issues. Of course any issues please provide feedback via the form on the home page. Thanks and as always your time is appreciated.

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, 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

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'.

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/