This is part 2 of a multipart blog series on RedELK: Outflank’s open sourced tooling that acts as a red team’s SIEM and also helps with overall improved oversight during red team operations.

In part 1 of this blog series I have discussed the core concepts of RedELK and why you should want something like this. In this blog post I will walk you through integrating RedELK into your red teaming infrastructure. In future parts I will explain the core functionality of RedELK, and on the alarming of detection by blue teams.

In this blog I use the 1.0.1 release of RedELK . You can get it here.

Core concepts of RedELK

RedELK should be regarded as an addition to your red teaming infrastructure. Your operation will continue without RedELK. However, you will soon experience that an ops without RedELK feels like working partly blind.

There are a few core concepts that help you better understand how RedELK works and that help you with an easy deployment:

• A separate RedELK instance is intended per engagement. It is not recommended to mix operational data from multiple engagements into the same RedELK server.
• Each RedELK installation consists of the following three components:
  1. RedELK server;
  2. redir package installed on each of your redirectors;
  3. teamserver package installed on each of your C2 servers.
• RedELK allows you to define different attack scenario names within a single engagement. This is useful for multi-scenario engagements such as TIBER, e.g. scen1, scen2 and scenX. You could also use this to differentiate between different campaigns or otherwise differentiate between multiple goals for the same client, e.g. phisrun1, longhaul, shorthaul4, etc.
• Hopefully you already have the good practice of deploying new infrastructures per red team engagement. You should treat the RedELK server in the same way: install freshly at new engagements. Upgrading or re-installation of RedELK is not supported.
• A RedELK server is of high confidentiality as it stores all operational data as well as all traffic data. You may want to position this in a secured network segment.
• Inbound traffic to a RedELK server is limited to HTTP for the Kibana web interface and TLS-encrypted filebeat->logstash traffic from your redirectors and C2 team servers. A RedELK server initiates outbound rsync traffic to your c2 team servers and HTTP(S) to online security vendor such as Virus Total, abuse.ch, malwaredomains.com, Greynoise, etc.
• The performance impact on your redirectors and C2 team servers is very limited: it is only filebeat that is installed on both, and a little cron script to copy logs to a central directory on the C2 team servers.
  A RedELK server requires beefy hardware. It runs the full Elastic stack, and over time will contain a reasonable amount of data. A dual core CPU and 8GB RAM is recommended.
• Redirectors serve as anonymization layer in red team operations. However, in the case of RedELK their purpose is extended to also serve as a logging layer. This means it is recommended to point your Domain Fronting/CDN endpoints to a redirector that you fully control and where you have the RedELK redir package installed. If you point directly to your C2 team server, you miss the traffic data.

The picture below shows a better overview of how the different components interact and how the data flows to and from the RedELK server.

Lab network setup

For this demo, I have setup a lab with the following characteristics:

1. Target network with multiple machines.
2. Two attack scenarios, one for shorthaul and the other for longhaul.
3. Two Cobalt Strike Team servers, each for different purpose
4. Two redirectors, one running Apache, the other running HAProxy.
5. The Apache redirector is reachable via a Domain Fronting setup using Azure CDN. It sends its C2 traffic to a dedicated C2 server. Decoy traffic is sent to amazon.com
6. The HAProxy redirector sends C2 traffic to a different C2 server. Decoy traffic is sent to a decoy website we setup ourselves.

A general overview of the test lab setup can be seen in the picture below. Note that the RedELK server is not included in this overview:

Naming
RedELK has a few requirements to the naming of objects. These are explained indetail on the wiki. In this demo lab I use the following names:

Attackscenario: shorthaul

• CDN entry DNS name: ajax.microsoft.com
• CDN endpoint name: redelkdemo.azureedge.net
• CDN origin hostname: redira1.totallynotavirus.nl
• Apache redir DNS name: redira1.totallynotavirus.nl
• Apache redir FileBeatID: redira1
• Apache redir frontend name: http-AzureDF
• Apache redir C2 backend name: c2-c2server1
• Apache redir decoy backend name: decoy-amazon
• C2 server DNS name: c2server1.totallynotavirus.nl
• C2 server FileBeatID: c2server1

Attackscenario: longhaul

• HAProxy redir DNS name: redirb1.totallynotavirus.nl
• HAProxy redir FileBeatID: redirb1
• HAProxy redir frontend name: http-straight
• HAProxy redir C2 backend name: c2-server2
• HAProxy redir decoy backend name: decoy-staticerror
• C2 server DNS name: c2server2.totallynotavirus.nl
• C2 server FileBeatID: c2server2

RedELK server info

• RedELK server DNS name: redelk.totallynotavirus.nl

The CDN configuration is shown below. Don’t forget to set the caching behavior to ‘Bypass Cache’ within the Caching Rules rules of the endpoint. There are several blog posts explaining how to do this, including this great post by @rvrsh3ll.

Each Cobalt Strike server requires two things: the Mallable profile, and the listener setup. The Mallable profile I’ve used in this example is based on the same that ships with RedELK, and can be found here. Note that this profile requires you to insert the host header of your Domain Fronting CDN endpoint name. If you don’t want domain fronting you can remove the Host Header Host directive.

The important things with listener setup is to use a HTTP Host that is frontable, and to use the hostname of the CDN endpoint in the Host Header field.

The example above is for the CDN redir-teamserver setup. I have configured the other Cobalt Strike teamserver with a rather basic HTTP listener setup.

With the test lab setup explained, let’s focus on the RedELK specific installation.

Initial installation

First, download RedELK and extract the package. Check with version you get, there may be newer versions available:

curl -L https://codeload.github.com/outflanknl/RedELK/tar.gz/1.0.1 -o redelk_v1.0.1.tgz
tar zxvf redelk_v1.0.1.tgz

Before we can run the installers on the different systems we need to:

1. Generate TLS certificates used for the secured traffic between filebeat on redirectors/c2 team servers and the RedELK server
2. Generate three installation packages for redirectors, c2 team servers and for the RedELK server.

Both steps are done with the initial-setup.sh script. You can run this initial setup on the RedELK server, but it is also tested macOS clients.

Important note: Make sure to edit the details of the TLS Certificate Authority in the certs/config.cfg file prior to running the script. Make sure to not make typos here: TLS is non-forgiving, resulting in blocked data flows to your RedELK server. Troubleshooting is difficult, so pay attention while performing this step.

In this case I’ve configured the TLS config file to use redelk.totallynotavirus.nl as DNS.1, and I’ve removed the DNS.2 and IP.1 lines.
After editing the TLS config file, run the installer:

./initial-setup.sh certs/config.cnf

Output should look like:

Installation on redirector

In this demo setup I have created two redirectors, one running Apache (used via the CDN), the other running HAProxy for the direct HTTP communication. Both redirectors need the redirs.tgz package generated in the previous step. So copy them over to the remote systems.

Before we can run the installers on the redirectors we need to configure Apache and HAProxy to be more verbose in their logging. This requires a modified config. Luckily RedELK ships with example configs for these extra logging directives, and can be found here. Let’s walk through the required steps.

Redirector setup

I will start with the Apache one. We need to enable required Apache modules, make a new site, configure the new site according to the Cobalt Strike profile and according to the RedELK logging requirements. This can be done as following:

apt-get install apache2
a2enmod rewrite proxy proxy_http proxy_connect ssl proxy_html deflate headers
a2dissite 000-default.conf
curl https://raw.githubusercontent.com/outflanknl/RedELK/master/example-data-and-configs/Apache/redelk-redir-apache.conf -o /etc/apache2/sites-available/redelkdemo.conf

Now open Apache config file, change the two occurrences of $$IP_OF_YOUR_C2SERVER to your C2 team server’s address (in my case c2server1.totallynotavirus.nl), define a friendly hostname (in my case redira1) and make sure to configure an informative name for the frontend (in my case www-http) and for the backends (in my case decoy and c2). See example in screenshot below.

Enable the site and start apache:

a2ensite redelkdemo.conf
service apache2 restart

As traffic hits your redirector the log file /var/log/access-redelk.log should be filled.

Now it is time to run the RedELK redir installer. Copy the redirs.tgz package from the initial setup step over to your redirector. Extract the tgz file and run the following command:

install-redir.sh $FilebeatID $ScenarioName $IP/DNS:PORT

In my case I ran:

./install-redir.sh redira1 shorthaul redelk.totallynotavirus.nl:5044

The installer should exit without errors, and filebeat should be started. Note that the filebeat log file will report errors as the RedELK server isn’t configured yet so the incoming Filebeat traffic is not acknowledged.

The setup of the HAproxy redirector is largely similar. You can find an example config here. The RedELK installer command I ran is:

./install-redir.sh redirdb1 longhaul redelk.totallynotavirus.nl:5044

Installation on C2 team server

The installation on the Cobalt Strike C2 teamservers is rather straight forward. Copy the teamservers.tgz package to the teamserver and run the installer using:

install-teamserver.sh $FilebeatID $ScenarioName $IP/DNS:PORT

These parameters should sound familiar.
I’ve ran the following command:

./install-teamserver.sh c2server1 shorthaul redelk.totallynotavirus.nl:5044

Important note: you want to keep the $ScenarioName the same as used during installation on the redirector. If you’ve failed to do so, or want to rename the scenarioname or the host at a later moment, just edit the fields in the /etc/filebeat/filebeat.yml file.

The installation on the other c2 team server is roughly the same, of course using FilebeatID c2server2 and scenario name longhaul.

Installation on RedELK server

The installation on the RedELK server requires no parameters. Just copy and extract the elkserver.tgz file, and run:

./install-elkserver.sh

You should see something like this.

As the installer tells you, there are a few mandatory things left to do:

1. edit the configuration /etc/cron.d/redelk. This is required to rsync the Cobalt Strike logs, screenshots, downloaded files, etc to the local RedELK server. This *greatly* enhances ease of use during the ops.
2. edit the configuration files in /etc/redelk/. I recommend at least the alarm.json.conf if you want alarms, and iplist_redteam.conf to define what external IP addresses are used for testing purposes and you naturally don’t want alarms on. But please check out all the details as also described at the RedELK wiki

See below screenshots for the edits in my example.

Test the access

Browse to the HTTP port of the RedELK server. Login with your own creds, or use the default redelk:redelk. As soon as data is flowing you should find data in the indices.

Do you see data? Great! In the next blog post I will walk you through the specifics.

Troubleshooting

Still no data there? Here are some troubleshooting tips.

• Did any of the installer packages report any error? If so, check the local installer log file.
• Did you use the correct name for the TLS setup in the initial-setup.sh script?
• Did you point filebeat to the correct DNS name or IP address? Check /etc/filebeat/filebeat.yml for the value of hosts. The value should match to something listed as DNS or IP in the TLS config file for the initial-setup.sh.
• Is Filebeat correctly sending data? Check /var/log/filebeat/filebeat on redirs and teamservers. Sadly, the exact error messages are cryptic at best. In our experience, most often it comes down to a TLS-DNS-certificate mismatch.
• Is Logstash on the redelk server reporting errors in /var/log/logstash/logstash-plain.log?
• Are there any beacons running, and/or is there traffic flowing to your infra? If not, well, RedELK doesn’t have any data if there is no data
• “It is not DNS. It can’t be DNS. Ah crap, it was DNS.” Make sure the DNS records are correctly configured.
• Check the wiki of the project.
• Still having issues? Create an issue at GitHub.

The post RedELK Part 2 – getting you up and running appeared first on Outflank.

When we debuted OST back in 2021, we wrote a blog detailing both the product features and the rationale for investing time into this toolset. In 2022, we joined forces with Fortra and we can hardly believe it’s been over a year already. It was a big decision to go from being a small team of red teamers to becoming part of a large company, but we’re very pleased with the switch. In this reflection on the past 12 months, we want to provide an update on our mission, detail our continued dedication to OST, discuss the process of growing the Outflank community, and touch on where we’re headed next.  

Read more: Reflecting on a Year with Fortra and Next Steps for Outflank

A Product Oriented Focus

One of our biggest challenges when we joined Fortra was the decision to put most of our energy into Outflank Security Tooling (OST). Everyone on the team is a dedicated security consultant with years of experience in conducting complex red team engagements, so shifting much of our focus to a product was unfamiliar territory. While there was some initial discomfort, the adjustment was well worth it. We have enjoyed being able to spend much more time on research and development and to be able to create novel new tools that had real value.

A big reason this transition has been so successful is the additional resources and support provided by Fortra, a company that has a strong foothold in the cybersecurity space and is familiar with its challenges, like export controls and quality control. Fortra is particularly well versed in offensive cybersecurity, with multiple solutions that focus on pinpointing risks. With their acquisition of Cobalt Strike, they have already proved that they know how to successfully manage and foster the continued growth of advanced red teaming tools with unique R&D needs.

We have also greatly benefited from having access to extensive knowledge from colleagues in supporting areas like sales, customer support, legal, and marketing. Knowing we can confidently hand off tasks to these experienced teams has allowed us to go full throttle on the technology, of which we remain fully in charge. Additionally, we’ve been able to take advantage of the other R&D teams. This is particularly true with Cobalt Strike’s experts, which we’ll go into more detail on later on.

A Fruitful Year: New OST Tools Released

Our increased focus on OST is evident by the steady expansion of the toolset. In the past year alone, we’ve added the following new tools and capabilities:

• Stage1 v.2: A major overhaul of our C2 framework. It now supports BOFs, Socks proxying, C2 via HTTPS, SMB, raw TCP and files, and many more other features, while keeping the extreme OPSEC focus alive.
• Cobalt Strike Integrations: An easy way for operators to make use of custom UDRLs and custom Sleep Masks straight onto their Cobalt Strike payloads.
• New EDR Evasion: Super effective techniques embedded in tools such as Payload Generator and Stage1 implant generator. This includes DRIP allocations, ROP gadgets, and stealthy loading techniques.
• Hidden Desktop v2: A significant rewrite of Hidden Desktop in BOF format that is stealthier, faster in operation and easier in deployment.
• KernelTool and KernelKatz: Uses the power of vulnerable kernel drivers to directly interact with the Windows kernel to scrape credentials and/or modify other processes while EDRs let you through.
• EvilClicky: An easy way to abuse ClickOnce functionality.
• KerberosAsk: Updated to enhance Rubeus-like Kerberos trickery, in an OPSEC safe and in BOF format.

Expanding the OST Community

This increase in development has progressed us from crawling to walking, but growth in other areas has really made us feel like we’re now keeping a steady running pace.

While we’re working hard on new tool additions, we’ve also run multiple knowledge sharing sessions for OST users, covering topics like EDR evasion, Windows Kernel drivers, ClickOnce technique and Stage 1 C2 automation. We have been able to onboard many more red teams. Coupled with the fact that the Outflank team is more available on the Slack community and more red teams are coming to discuss ideas, the OST community is in a way better position that it ever was.

Not Forgetting What Makes Us Outflank

We’ve continued to conduct some trainings and red team engagements this last year, as this remains a core function of Outflank. Not only is it something we’re all passionate about, but it also helps in our development of OST. A critical part of R&D is to stay current on what red teamers are seeing in the wild. Running engagements keep our skills sharp and allow us to keep a pulse on the needs of other red teamers.  

An Expanding Team of Experts

One of the key factors in choosing to become part of Fortra was the opportunity to work with the Cobalt Strike team. We have used this benchmark product since the inception of Outflank and have designed OST to work both in tandem and together with Cobalt Strike (although OST certainly can be used independent of Cobalt Strike). Becoming coworkers with this welcoming, intelligent team has been as valuable as we hoped it would be. Both products have benefited from having added perspectives and the success of our collaborative efforts are already evident, with new integrations like our custom User Defined Reflective Loaders, custom Sleep Masks and YARA based payload analyses. While our products will remain independent, it’s clear that there are countless possibilities for innovation and alignment that we’re excited to continue to explore.

The Outflank team has also grown. As a small team that relies on effective communication and joint efforts, we carefully considered the potential outcomes of adding new members. We wanted to ensure they were a good fit and that we were adding expertise that would help OST continue to excel. With this in mind, we recently welcomed Tycho Nijon, our first full stack developer who is focusing on broader application development and Kyle Avery, a principal offensive specialist lead who is more focused on specialized research and development.  

The Ongoing Evolution of OST

Perhaps the biggest takeaway from this past year has been the overwhelmingly positive response from the market. Simply put, many red teams do not have the desire or resources to develop their own tools. At the same time, EDR tools are rapidly becoming more powerful, requiring red teams to double down on their OPSEC. OST fills that gap. Ultimately, we found that modern red teams really require support from beginning to end, from initial access to actions on objectives, from tooling to knowledge. With Outflank being part of Fortra, we are better equipped than ever to deliver solutions to meet these needs. Moving forward, OST customers can expect more Q&As, info sessions, and of course, new tools that expand and simplify red team capabilities.

If you’re interested in seeing all of the diverse offerings in OST, we recommend scheduling an expert led demo.

The post Reflecting on a Year with Fortra and Next Steps for Outflank appeared first on Outflank.

We are hosting a free training on Microsoft Office Offensive Tradecraft aimed at red teamers. Head over here for more details and for registration.

The post Free Training: Microsoft Office Offensive Tradecraft for Red Teamers appeared first on Outflank.

Malicious actors continuously deploy new or improved techniques. Red teams must maintain an equally rapid pace of development of their tooling arsenal to remain effective at testing evolving defensive measure and preparing organizations for advanced threats. With the dedicated research and development efforts from the Outflank team, OST is constantly evolving, with additions of new, leading-edge tools unique to the market as well as regular enhancements to our existing tools. 

In this quarterly release blog, we’ll summarize some of the latest updates we’ve made over the past few months.  

EDR Tradecraft

Over the last few years we have clearly seen the big EDR names in the market up their game. Generally, we can say that they are doing a great job and that EDR-bypasses are becoming harder. However, EDRs can’t be expected to do magic, so there are still impressive, highly technical techniques that completely fly under the radar of even top tier EDRs.  

An important change here is EDR bypass diversification: techniques that bypass all EDRs in one go are now increasingly less common. It is becoming more important for red teamers to know which exact technique to use (or not use) for a specific EDR. Up-to-date knowledge is important—particularly knowledge on how a specific EDR gets its data, how it works under the hood and where its blind spots and bypass opportunities lie. For OST we aimed on better equipping our customers with exactly that: knowledge. 

Our experts spent months conducting deep technical research on the inner workings of major EDRs on the market. This resulted in significant updates to our documentation, detailing relevant details on the inner workings of EDRs, detailing generic bypass techniques, and major EDR specific techniques to use and techniques to not use. In our analysis of the behavioral detection methods of major EDRs, we were also able to both broaden our findings to provide strategies for general EDR evasion and create a methodology for when a more targeted approach is needed to avoid detection.   

EDR Presets: An Opportunity for Community Sharing 

We didn’t stop at EDR tradecraft knowledge in written form. We also wanted to make it more tangible and readily available in some of our tools. We started with what we call “EDR Presets” in our Payload Generator. 

Payload Generator allows red team operators to easily create payloads with a wide range of decoy tricks, binary transformation options (such as prepending random shellcode), payload transformation options (such as encoding), encryption and compression, encryption possibilities, process creation techniques (such as Write Hook, KernelCallbackTable, Earlybird, in-process thread), as well as OPSEC tricks,  guardrails and many more. The total set of option combinations easily surpasses a hundred, and it is critical to select the proper combination to bypass specific EDRs. EDR Presets are configuration sets of these 100+ settings in the Payload Generator.  

Each EDR Preset has demonstrated the ability to evade detection by a certain EDR system at specific points in time. Though presets are incredibly useful and are a significant time saver for red team operators, they do have a limited shelf life. In order to maintain an up-to-date library of effective presets, we obviously perform ongoing lab testing. But as OST has a large community of active users, we decided to use that power of the community. We have implemented a secure way where OST users can contribute such presets they discovered during their engagements. This collaborative effort highlights the benefit of being a part of a strong user community, providing access to a collective pool of knowledge from which everyone can benefit. 

Although this was simple in theory, the implementation took some time. Ultimately, it was very much worth the effort. EDR presets have quickly become a key feature that OST customers like, and we are proud to say that the community is actively using the sharing functionality.  

PowerShell Tradecraft 

PowerShell is often difficult to use in an OPSEC safe manner, as it can be challenging to sufficiently obfuscate. However, we have developed a new technique that, using some PowerShell trickery, allows for stealthy lateral movements. We’re not sharing too many details here on purpose because, as far as we know, this is not a publicly known technique. 

Our tool can be used on its own, but we also wanted to integrate this in both Cobalt Strike and our own C2: Stage1 C2. The latter meant we needed to make Stage1 have support for PowerShell as well, so we went ahead and added this functionality.  

New Microtools 

While OST contains many tools with multi-functional capabilities, there are also times when a smaller tool is what’s called for. Two new tools we added this quarter were: 

• WSManexec: This BOF to the internal C2 tool collection enables remote command execution via WSMan (the protocol used by WinRM) in a stealthy manner 
• Keyper: This is a simple yet effective .NET keylogger that we created in response to user requests. It’s fully compatible with Stage1 and Cobalt Strike, but can also be useful as a standalone tool.  

Additional Updates 

• Stage1: The speed of SOCKS tunneling has been greatly accelerated.
• PetitPotam and PetitSystem:  The PetitPotam and PetitSystem BOFs now have wider system support for Windows 10/11 desktops and servers. The RPC interface that was used by PetitPotam/PetitSystem to trigger EFS is no longer present on new Windows 11 clients. We researched alternative interfaces and made an update that supports both older and newer Windows versions. While this interface is not running by default, the tooling now triggers the EFS service to start first, after which the interface will be accessible. 
• LAPSDump: This BOF now supports LAPS version 2. 

The Continuing Growth of OST 

Our formula for success with OST has consistently been grounded in three key pillars in order to support other red teams: tools, tradecraft, and community. Developing novel new tools that simplify and enhance engagements, offering educational opportunities that provide insightful new intel, and cultivating a solid community that facilitates connections and the exchange of experiences has enabled sustained growth and expansion. This proven formula also positions us to continue innovating, and we can’t wait to share more of what we’re working on.  

If you’re interested in seeing all of the diverse offerings in OST, we recommend scheduling an expert led demo. 

The post OST Release Blog: EDR Tradecraft, Presets, PowerShell Tradecraft, and More  appeared first on Outflank.