Previous

Assumed Breach

Preparation for Internal Attacks

I think we can all agree in IT security that there is no such thing as 100% protection against cyber attacks. In the Assumed Breach scenario, we assume that a malicious attacker has already gained access to your internal network. Compromised trusted internal connections (Trusted Relationship or Valid Accounts) are one possible scenario. Another example is the classic trainee scenario.

Assumed breach bild 1 v1

In the assumed breach scenario, I answer key questions about your IT security: How far can an (internal) attacker get into your network in the post-breach phase? Is it possible for an unauthorised user to access sensitive customer data and extract it through various channels? Are there vulnerabilities or misconfigurations in Microsoft Active Directory (AD) that could lead to a compromise of your Active Directory? Are your internal defenders aware of unauthorised activity on the network and how quickly do they respond? What is your network and endpoint visibility?

Assumed breach bild 2 v1

Are there vulnerabilities or misconfigurations in Microsoft Active Directory (AD) that could lead to a compromise of your Active Directory? Are your internal defenders aware of unauthorised activity on the network and how quickly do they respond? What is your network and endpoint visibility?

How I Proceed in the Assumed Breach Scenario
  • 01
  • 02
  • 03
  • Planning | Scoping

    The first step is to define a possible scenario for the assumed breach assessment in consultation with my clients - this could be an internal scenario, for example. Then we define possible targets - this could be the compromise of the CEO account or his workstation, the compromise of certain user accounts (e.g. system administrators) or the takeover of the Microsoft Active Directory. Ideally, as few employees as possible should be involved (white team), as this will give you a truly realistic and undistorted picture of the ACTUAL state of your current IT security and IT defence level.

    Scope v2
  • Methodology | Implementation

    Depending on the defined scenario, I might start as an unprivileged user on one of your Windows clients in your domain. I start with an initial internal discovery and get a first overview of your internal infrastructure, possible vulnerabilities, misconfigurations in Active Directory, etc. I then try to find the best possible solution. Based on this, I try to achieve the pre-defined goals in the post-breach phase. Compared to an internal penetration test, I act as inconspicuous as possible and play to my strengths in the area of defence evasion. At the end of the day, you gain valuable insight into the strengths and weaknesses of your EDR and how your internal defenders react to the cyber-attack, or whether they even notice the activity on their own network.

    Umsetzung v2
  • Report | Further Development

    The Assumed Breach Assessment concludes with a final report and presentation. You will be given a clear picture of your current strengths and weaknesses, both technically and defensively. How far have I come? Have I achieved my objectives? How is your sensitive corporate data being protected? What activities have your internal defenders noticed? How did your defenders react to the cyber attack in general? How did your EDR react in the different post-breach phases (detection and response)? The answers to these questions will help determine the next steps.

    Weiterentwicklung v1
Why Assumed Breach at RedOps?

In the Assumed Breach scenario, I follow the Red Team approach, except that the Initial Access phase is omitted. Using my strengths in defence evasion, I put your defenders to the test.

With RedOps I take a holistic and realistic approach. At the end of the day you will have an undistorted picture of the current ACTUAL state of your defenders and your technical IT security.

Responsibility Research Quality

  • Responsibility and Integrity

    Anyone who uses offensive security services and deliberately exposes themselves to an ethical hacking attack should do so with a partner they can absolutely trust. I keep all information strictly confidential and am 100% integer in what I do.

  • Research Orientation

    IT security is not a product, but a constant learning process. That's why I invest a lot of time in further education and research. I have already been able to present my results in the area of endpoint security at several international IT security conferences.

  • Quality Instead of Quantity

    With Offensive Security, I have made my passion my core competence. I don't sell products or licences, but live purely from my expertise in the field of IT security. For me, quality clearly comes before quantity.

Making sense of IT:Security