--- ### 1. Set up Active Directory I started by setting up a basic Active Directory domain — the kind of thing that quietly runs the backend of a lot of organizations. I followed [this IBM guide](https://www.ibm.com/docs/en/storage-scale-bda?topic=support-install-configure-active-directory) as a reference just to make sure I wasn’t missing anything big. I named the domain `blackridge.local` to match the fictional bank this lab is built around. #### How I structured it Instead of throwing all users and computers into a giant, chaotic pile, I used **Organizational Units (OUs)** to separate things cleanly by site. That’s how it’s done in real orgs, especially those with multiple offices. At the top, there’s a master OU called `BlackridgeBank`, and under that I split it into three logical locations: - `Headquarters` - `Lincoln Branch` - `Remote` Each site has two OUs inside it: - `Users` → for the people - `Computers` → for the machines This setup makes it way easier to apply policies later on. For example, I can give different settings to just Remote workers or push a drive mapping only to Lincoln Branch. It also makes group policy targeting and delegation feel a lot more organized. ![[assets/AD structure.png]] --- ### 2. Created Groups for RBAC Once the OU structure was in place, the next thing I tackled was access control. And to be honest, I didn’t feel like manually assigning folder permissions to 100 users one at a time — that’s a headache even in a fake environment. So instead, I went with a **group-based model** using something called **role-based access control**, or [RBAC](https://www.digitalguardian.com/blog/what-role-based-access-control-rbac-examples-benefits-and-more) for short. RBAC just means people get access based on **what they do**, not who they are. If you're in the IT department, you're part of the IT group. If you're an intern, you're in the intern group. Then, I give those groups access to what they need — once. No micromanaging. To keep it consistent and recognizable, I used the naming convention `GG_` for “Global Group.” It makes them easy to spot and filter later. Here are the ones I created: - `GG_IT_Admins` — for sysadmins and IT staff - `GG_Interns_Limited` — interns, with limited permissions (read-only in most places) - `GG_Finance_Read` — finance team, with modify access to financial folders - `GG_HR` — HR staff, access to employee-related files - `GG_CS_Users` — customer service reps - `GG_Audit_Read` — for internal/external auditors (read-only) - `GG_Execs` — executive team, C-suite, board members Once these groups were built, it was super easy to assign folder permissions, set GPOs, or delegate access. And later in the project, some of these groups (like `GG_Interns_Limited`) will be misused — on purpose — to simulate insider threats. ![[assets/gg_groups.png]] ![[assets/group_creation.png]] --- ### 2.5. Deployed 100 Users and Groups via PowerShell To automate the creation of users and groups in Active Directory, I wrote a script called . [[Hands-on Labs/HollowRoot/Scripts used/deploy-blackridgeAD.ps1|deploy-blackridgeAD.ps1]] This saved _hours_ of manual clicking and ensured the setup was repeatable and clean. What it does: - Checks if security groups like `GG_IT_Admins`, `GG_Audit_Read`, etc. already exist — if not, creates them inside `OU=Groups` - Creates 100 users with realistic names, titles, departments, and human-like passwords (e.g., `Kevin6398#`) - Places users in department-based OUs inside the correct site (`Headquarters`, `Lincoln Branch`, or `Remote`) - Adds each user to their appropriate security group (e.g., `GG_CS_Users`, `GG_Interns_Limited`) - Logs usernames and passwords to `C:\Blackridge_AD_100Users_Log.txt` for testing and validation - Smart logic: - Uses `if (-not (Get-ADUser ...))` so it won’t duplicate users on rerun - Passwords are passed using `ConvertTo-SecureString`, but they are still in plaintext (okay for a controlled lab environment) - Adds final elevated access for `edrake` and `sbanks` to `GG_IT_Admins` and `Domain Admins ![[assets/deployscript.png]] The end result: a fully built, realistic Active Directory environment that's ready for red and blue team testing, complete with users, departments, and RBAC structure — all generated in minutes instead of hours. --- ### 3. Created Department Folders Made folders at `C:\` to simulate network drives you'd see in a real org. - `C:\ITS_Tools` - `C:\InternFiles` - `C:\FinanceShare` - `C:\HRDocs` - `C:\AuditLogs` - `C:\CS_Docs` - `C:\ExecReports` These will be accessed over the network and mapped via drive letters later. ![[assets/department_folders.png]] --- ### 4. Locked Down NTFS Permissions By default, all domain users had read access — no thanks. I tightened each folder’s permissions using NTFS: Steps: - Right-click folder → Properties → Security → Advanced - Disable inheritance → Convert permissions - Removed `Users (BLACKRIDGE\Users)` - Added only: - The correct `GG_` group - `Administrators`, `SYSTEM`, `CREATOR OWNER` Example from `ITS_Tools`: ![[assets/step4a.png]] ![[assets/step4b.png]] ![[assets/step4c.png]] ![[assets/step4d.png]] --- ### ✅ Folder Permissions Summary | Folder | Group | Permission | |----------------|----------------------|----------------| | ITS_Tools | GG_IT_Admins | Full Control | | InternFiles | GG_Interns_Limited | Read | | FinanceShare | GG_Finance_Read | Modify | | HRDocs | GG_HR | Modify | | AuditLogs | GG_Audit_Read | Read | | CS_Docs | GG_CS_Users | Read | | ExecReports | GG_Execs | Full Control | --- ### 5. Seeded Fake Enterprise Data Wrote a PowerShell script [[Seed-MockBankData.ps1]] that adds fake but realistic files to each folder: - `Q1_Profit_Loss_2025.xlsx` - `Wire_Transfer_Template.docx` - `Employee_Compensation_Grid.xlsx` - `Intern_Onboarding_Guide.pdf` - `Executive_Credentials_Backup.txt` 😈 Also: - Adds fake content to `.txt`, `.csv`, `.ps1` - Randomizes file timestamps to make it feel lived-in ![[assets/fakefiles.png]] --- ### 6. Shared All Folders Over the Network (SMB) Each department folder is now shared using **Advanced Sharing** with correct group-level permissions. Example: - Shared `C:\InternFiles` as `\\d01\InternFiles` - Share permissions: - Removed `Everyone` - Added `GG_Interns_Limited` with **Read** access ✅ Share Access Paths: - `\\d01\ITS_Tools` - `\\d01\InternFiles` - `\\d01\FinanceShare` - `\\d01\HRDocs` - `\\d01\AuditLogs` - `\\d01\CS_Docs` - `\\d01\ExecReports` ![[assets/folder_network_access.png]] --- ### 8. Grant RDP Access to Server for IT admins To allow members of the IT team to RDP into DC01 and other servers, I added the `GG_IT_Admins` group to the **Remote Desktop Users** local group on DC01. This ensures any future IT users (like interns or junior admins) who are added to that group can log in remotely without being full domain admins. ![[assets/rdp.png]] ![[assets/rdp2.png]] ### 9. Built Windows 10 Test Machine Made a Windows 10 VM in Proxmox to simulate a normal user workstation. Steps: - Installed from ISO - Named the PC something like `W10-Client01` - Manually pointed DNS to the DC’s IP: `192.168.1.20` ✅ - Joined domain: `blackridge.local` - Logged in as IT staff (e.g., `blackridge\tzane12`) ![[assets/joined_domain.png]] - checked if the folders i could access were accessible and the ones I didn't weren't ![[assets/deny_acess_folder.png]] --- ### ✅ Current Lab Status - [x] AD domain: `blackridge.local` up and running - [x] Users + groups structured and realistic - [x] Folders with NTFS + share permissions mapped by group - [x] Fake data in place for red/blue team testing - [x] Client PC joined to domain and fully functional - [x] Shared folders fully accessible from client --- ### 10. Cloud Setup (Azure Side of Blackridge Bank) To mirror what you'd see in a real hybrid company, I built out a cloud environment using a free Azure account. This is **Blackridge Bank's cloud side** — but it's just as messy and unstructured as the on-prem side. Most companies (especially fintech startups) start with Active Directory, then bolt on Azure later without cleaning things up. That’s exactly what I wanted to show here: **a loosely connected, over-permissioned Azure setup that an insider could totally abuse.** --- ### 👥 Azure IAM Users These are the accounts I created to simulate typical employees, but with bad cloud identity management: - **`[email protected]`** – Finance > Should only have limited read access to finance stuff, but was added to the full admin group. - **`[email protected]`** – Executive > A Domain Admin on-prem who got recreated manually in Azure and given Global Admin. Terrible identity lifecycle. - **`[email protected]`** – DevOps > Has long-lived access keys that end up hardcoded in a `.ps1` script. These get leaked and used by Eliot. - **`[email protected]`** – Simulated hybrid identity > A manually created Azure account to mimic a synced AD admin. Same name and password reused — no federation, no real sync. ![[assets/create_user_cloud.png]] ![[assets/cloud_user1.png]] ![[assets/cloud_user2.png]] ![[assets/cloud_user3.png]] --- ### 🛡️ IAM Group: `CloudAdmins` - I created a group called `CloudAdmins` and gave it **full Global Admin rights**. - Then I added _everyone_ — finance, execs, DevOps, even the fake AD user. - There’s no conditional access, no MFA, and no role scoping. 🧠 This mirrors real orgs where privilege just spreads because no one locks things down. ![[assets/cloudadmin.png]] ![[assets/global_admin.png]] --- ### 🗃️ What is a Blob / Container? In Azure: - A **Blob** is basically a file — could be a document, script, photo, anything. - A **Container** is like a folder that holds blobs. - A **Storage Account** is the top-level thing that holds all your containers. So for Blackridge: - I created a storage account for finance data - Inside that, I created a container called `financial-data` - Then uploaded sensitive docs — and **left it open to the public** --- ### 💾 Storage Setup: `blackridgefinance` - Created a storage account ![[assets/cloud_storage.png]] - I left **anonymous access enabled** — because someone forgot to disable it during the rushed cloud migration. ![[assets/blob_access.png]] - Created the `financial-data` container ![[assets/new_container.png]] - Uploaded fake files: - Exec compensation - Audit findings - Cloud keys ![[assets/cloud_fake_files.png]] --- ### 🔐 Key Vault Setup - Created `blackridge-vault` ![[assets/keyvault_creation.png]] - For “convenience,” Blackridge added **everyone** to Secrets Officer ![[assets/role_assignment.png]] - Added 3 fake secrets: - `slack_token` - `prod_db_pass` - `azure_key_pair` ![[assets/cloud_secret.png]] ![[assets/3_cloud_secrets.png]] --- ### 💣 Dropped .ps1 Script on DC01 - File path: `C:\ITS_Tools\CloudSync_Backup.ps1` - Hardcoded credentials + Azure login command - This is what Eliot finds during Phase 2 and uses to pivot into Azure ![[assets/planted_ps1.png]] ### 11. Deliberate Bad Practices (Seeded for HollowRoot Red Teaming) To prep for Phase 2, I intentionally added weak configurations and poor security hygiene — the kind of stuff you still see in real companies. These open up realistic attack paths for a rogue insider to abuse. --- #### Weak, Human-Guessable Passwords - User passwords follow easy-to-guess patterns (e.g., `Kevin6398#`, `Rayna6091@`) - Most are just names + birth years, reused across accounts - No real randomness or complexity enforcement - Passwords are stored in plaintext in: `C:\Blackridge_AD_100Users_Log.txt` ![[assets/100user.log.png]] --- #### Overprivileged Accounts - **Eliot Drake (`edrake0`)**, an intern in IT, was added to `GG_IT_Admins` ![[assets/edrake_op.png]] - **Sandra Bank (`sbanks`)**, an executive, was added to `Domain Admins` (Too much power for non-technical staff) ![[assets/sbank_op.png]] --- #### Excessive Access via GPOs (Planned) Will deploy GPOs that: - Map sensitive folders (like `ITS_Tools`) to **all users**, regardless of role - Enable **PowerShell and RDP access** across the board - Skip proper access control — no separation of duties or least privilege enforcement This simulates sloppy internal controls often seen in rushed setups or during org growth. --- #### Poor Logging & Monitoring (In Progress) - No Sysmon or advanced logging installed - PowerShell transcription logging is disabled - No centralized logging, no SIEM - Audit policy is default — no alerts, no correlation - Event logs can roll over or be cleared without detection This sets the stage for stealthy abuse and delayed incident response. --- #### Weak Password Policy Default domain policy is still mostly untouched. It allows: - Short passwords (min = 7 characters) - No account lockout — unlimited login attempts - Password history is set (24 remembered), but still vulnerable due to the simple patterns allowed ![[assets/bad_pw_practice.png]] ![[assets/bad_pw_practice2.png]] #### ☁️ Cloud-Side Weaknesses - **No MFA Anywhere** Not enforced on any account, including Global Admins and Key Vault users. ![[assets/no_mfa_cloud.png]] - **Overpowered Group: `CloudAdmins`** - Everyone was added to this group: finance, execs, interns, IT - Given **Global Administrator** permissions - No scoping or access separation - **Public Blob Storage** - Anonymous access was left on for `financial-data` - Anyone with the URL can view/download sensitive finance docs - **Hardcoded Azure Credentials in PowerShell Script** - Leaked in `C:\ITS_Tools\CloudSync_Backup.ps1` - Contains cloudadmin credentials and Azure login logic - **Key Vault Exposed** - `blackridge-vault` was created without RBAC scoping - All CloudAdmins are Secrets Officers - No expiration or secret rotation - **Reused Identities Between On-Prem and Cloud** - Example: `[email protected]` exists in both environments with the same password - No federation or lifecycle management — just copy-paste identity reuse - **No Detection in Azure** - No Defender for Cloud - No Key Vault logging - No access review policies - No alerting on privilege abuse or sign-in anomaly These weaknesses will fuel red team escalation paths in Phase 2 and 3 — allowing an intern or compromised account to slowly climb the ladder, evade detection, and access sensitive systems. ---