A Push Toward Transparency

Information security is a young field, which is still rapidly evolving compared to professional industries that have been around for centuries (e.g. medicine). Similar to information security, medicine is designed to be both a profitable business and serve a public good. Thousands of years have been spent by medical researchers contributing in their field, sharing hypotheses, and adding to the collective body of knowledge. To advance a hypothesis in medicine, it must be openly studied, verified, peer reviewed, and defended. This system has meaningfully and continually improved the effectiveness of practitioners in the medical profession. Contrast this with the current information security profession. Ideas, hypotheses, and research efforts are rarely shared because many see this as giving away competitive advantage. The problem with this approach is that it slows progress by limiting the spread of knowledge. While there are certainly limits, we strongly advocate on the side of transparency in information security.

At SpecterOps, we believe that the way we can influence the maturation of our industry is through our contribution to the collective knowledge base. We believe that to make an indictment of the current system, we much first practice what we preach: opening our ideas and hypotheses to inspection and criticism. This is the foundation for our approach to transparency and a core tenet of our interactions with our customers and the community. By sharing our knowledge around adversary Tactics, Techniques, and Procedures (TTPs), in both simulation and detection, our hope is to illuminate weaknesses in systems that enable attack and invite collaboration to address those weaknesses.

Transparency in Action

Let’s examine a technology where security research was approached in a public manner: PowerShell. The capabilities of PowerShell for the security industry have come a long way in the past five years, thanks to internal champions at Microsoft and many industry champions that have pushed its advancement. However, this was not always the case. At one point, the attack surface presented by PowerShell in the enterprise was massive and poorly understood.

Several of our team members created a project in 2015, called PowerShell Empire, which was a culmination of previous industry work and projects with the added perspective of efficiency and the offensive research done by our team. Empire, at the time, was a pure PowerShell post-exploitation tool that showcased how adversary simulation activities could be replicated and enhanced with PowerShell. Since Empire’s inception, we have seen several additional offensive PowerShell projects start and push the body of knowledge even further and far more than any one organization could have alone. The effect of these projects allowed those in charge of the direction of PowerShell at Microsoft to make informed decisions on introducing additional security controls and features into PowerShell. We applaud the direction that Microsoft has chosen to take in introducing features like AMSI, script block logging, and others in more recent PowerShell versions.

To promote and enable the defensive use cases of PowerShell, our team members created PowerForensics, enabling investigative capabilities previously available primarily in heavyweight tools. Continued research through projects such as Get-InjectedThread, with features commonly associated with endpoint agents or memory forensics, further enable the lightweight detective and investigated capabilities the language can provide. Today, the use of PowerShell by attackers is becoming less enticing as offensive techniques become more well-known. In addition, we see wider scale deployment of PowerShell security features by many organizations. Both aspects represent an evolution of the security posture of the PowerShell language, driven by information sharing and transparency.

Our Commitment to Transparency in the Community

Every member of the SpecterOps team has drawn tremendous benefit from the sharing of knowledge through the community development of open source tools and methodologies. Each and every one of our team members is encouraged to contribute to the community with their research. Contributions tend to manifest as published blog posts, videos, and white papers to communicate our ideas. To solidify concepts, we believe that the creation and release of toolsets enable other security teams to understand and further build upon those ideas. Through these efforts, we hope SpecterOps has a greater impact in the industry outside of the clients we directly serve.

From an offensive research perspective, the work we do is often released as soon as it’s completed; there are no delay periods to gain an operational edge on future assessments. There must obviously be some exceptions to this rule, such as vulnerabilities for which responsible disclosure applies. Our intent in releasing adversary tradecraft publicly is to help the industry detect and mitigate working tradecraft that is being, or could be, used in real-world attacks. This could sound counterintuitive by “burning” extensive research efforts. However, we would make two counterpoints. One, the public release of potential attack techniques serve a public good by alerting the industry to a particular weakness. Two, in practice we have found that publishing tradecraft rarely immediately invalidates the research.

From a defensive research perspective, we acknowledge that the problem set for defenders is far greater than for adversaries, which is evident by the rising cost for an effective defense versus the cost of a successful attack. We believe that only through detection hypothesis and technology sharing can the industry counter adversaries with effectively unlimited resources. Hoarding of defensive capabilities only ensures that we fight as isolated teams against an enemy who roams the battlefield freely. For any “offensive” oriented research, we include immediate defensive steps and mitigations. For “defensive” research, we release capabilities that previously only a few products could perform. This does not mean we are “anti-product,” but that we believe that mitigation of adversary activity should be universal capability and part of a common body of knowledge. Projects such as PowerForensics, Bloodhound, Uproot, ACE, HELK and the Threat Hunter’s Playbook are examples of this methodology.

Our Commitment to Transparency to Our Customers

Too often in our industry, service and product offerings are a “black box” to customers. Customers are told to trust in marketing and/or reputation of the firm. We believe this does a disservice to their ability to achieving long-term meaningful improvement. For SpecterOps, if a customer wants to evaluate our capabilities, we have a series of public works and contributions to review. While conducting our services, we share with our customers the methodologies we use. Our goal is always to assist in building long-term knowledge and capability.

For example, in our adversary simulation assessments we believe value comes from the educational component of the assessment. In order to systematically break down the moving pieces of an attack chain, clients must understand the TTPs used during every part of that attack chain. We work to educate our client defenders to fully understand our approach and how we achieved our objectives. This may include performing live walkthroughs, providing tool or implant source code developed during the attack path, and giving training on how replicate the attacks (where possible) later. In our detection engagements, we document the TTPs we are attempting to detect and the methods we are using to conduct that detection. Not all TTPs are created equally in terms of prevalence, sophistication, and ease of detection. We work with the customer to ensure they understand what we search for, why those TTPs are selected, and how we gather and analyze the data. The objective of these engagements is to leave the customer with the understanding and capability to conduct effective collection and analysis activities, at some level, themselves.

The goal in all our services is to educate our clients and identify visibility and capability gaps within their defensive approach. If we provide an opaque assessment, we are doing a disservice to their ability to secure their systems. We believe organizations should have their own capability to validate security posture within their environments and not have to solely rely on third parties to understand their attack surface.

Conclusion

SpecterOps believes that a push towards transparency represents progress in our industry. As an industry that incorporates a mission of serving the public good, we should all demand more from ourselves than silos of advancement that create dependence on consultants and products. By collaborating and advancing the shared body of knowledge, we can confronts threats collectively that we could never effectively fight as individuals.

We won’t claim that we are the only proponents of open contributions industry. Indeed our team members, and many others, have practiced what we advocate for as a company for some time. We also won’t claim that we will release every idea or invention we create. There are often legitimate reasons a business must protect information. However, what we do, and will continue to do, is always error on the side of transparency.

Our ask: the next time you have a third party perform security testing in your environment, we encourage you to demand transparency. Ask questions. Try to understand the mindset and tooling. Do this not to just understand TTPs themselves, but to better equip yourself to help your defense team grow after the third party vendor has gone. Just as we reject security through obscurity as a strong control to protect client environments, we should also reject tradecraft efficacy through obscurity as well. We can effectively raise the bar in our field through collective education.