[This is a Guest Diary by Robert Cao, an ISC intern as part of the SANS.edu BACS program]

As a cybersecurity professional, I've always prided myself on my technical skills—understanding protocols, setting up secure systems, and knowing the ins and outs of firewalls and authentication mechanisms. But a recent deep dive into firewall and SSH logs taught me a lesson I wasn’t expecting: being technically savvy is only part of the equation. True success in cybersecurity also hinges on being an effective data analyst.

When I began examining the logs, I expected to find the usual culprits—brute force attempts, unusual traffic patterns, and the occasional misconfiguration. What I didn’t expect was how the data itself would tell a story far more valuable than any single technical fix. For instance, a repetitive pattern in the SSH logs from IP 137.184.185.209 showcased over 30 login attempts using common credentials like rootpaired with passwords such as Qaz@123456. At first glance, it seemed like just another brute force attempt. However, when I correlated this with firewall data, the same IP surfaced as repeatedly probing port 2222, a non-standard SSH port. Suddenly, it became clear: the actor wasn’t just relying on brute force; they were systematically targeting configurations presumed to be "secure by obscurity."

This realization made me question my own assumptions. In the past, I might have simply blocked the IP and moved on, feeling satisfied that I had applied a technical fix. But digging deeper into the data revealed patterns that informed broader strategies. Why was port 2222 being targeted? Could it be part of a larger campaign? These questions led to a more proactive approach: not just reacting to the attack, but trying to anticipate the next one.

Another revelation came from looking at overlapping datasets. By comparing SSH logs with firewall activity, I found four IPs—including 47.236.168.148 and 54.218.26.129—engaged in both brute force attempts and network probes. These actors were persistent, attempting to exploit systems over a short but intense window of time. Without correlating these datasets, I might have missed the coordinated nature of the attack entirely. This experience drove home the importance of cross-referencing data sources to uncover insights that no single log file could reveal.

Perhaps the most humbling realization was understanding that even advanced technical setups are only as good as the decisions behind them. Configurations that allowed root logins or didn’t enforce rate-limiting created vulnerabilities actors could exploit. As I analyzed the logs, I saw not just the actors' actions but also the blind spots in my own system's defenses. Technical knowledge helped me secure the systems, but it was the data analysis that highlighted the gaps.

This experience shifted my mindset. Cybersecurity isn't just about firewalls, encryption, and protocols—it's about understanding the data these systems generate. Data analysis is what transforms raw logs into actionable intelligence. It’s what turns a technically skilled professional into a strategist capable of predicting, preventing, and responding to threats effectively.

If there’s one thing I’ve learned, it’s that cybersecurity professionals must wear at least two hats: the technical expert and the data analyst. Technical skills build the foundation, but it’s the analysis of data that sharpens defenses and enables proactive security. As threats evolve and actors become more sophisticated, so too must our approach. Data is the key, and learning to harness its power is just as important as mastering the latest technical tools.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

I found a sample that is a Word document with an embedded executable. I'll explain how to extract the embedded executable with my tools.

First I check with file-magic.py:

The identification says Word 2007+, so this is an OOXML document. These are ZIP containers that can be analyzed with zipdump.py to take a look inside:

Stream 6 (oleObject1.bin) is an OLE object that embeds the executable. There's no need to extract that OLE file from the OOXML container, oledump.py can handle this:

The O indicator for stream A2 tells us that this stream is the OLE data structure embedding the executable.

Selecting this stream and using option -i gives us info about the OLE contained, and the contained file:

This metadata gives you the names of the embedded file and it hashes, allowing me to look it up directly on VirusTotal, for example: 3d5fe12c0aa783252431834ed8e370102f47df65165680824b9287faa88e088a.

The file can also be extracted with option -e:

Malicious Word documents like these don't execute the embedded file when the document is opened: that requires social engeneering to entice the use to double-click the embedded file.

Didier Stevens
Senior handler
blog.DidierStevens.com

The vast majority of red team exercises that I (and my team, of course) have been doing lately are assumed breach scenarios. In an assumed breach scenario (and we cover this in the amazing SEC565: Red Team Operations and Adversary Emulation SANS course that I also teach!) red team is usually given access as a non-privileged domain user, simulating an attacker that has someone already established the first foothold in the organization.

This works quite well as we know that eventually the attacker will succeed and perhaps get a victim (most of the time through some kind of social engineering) to execute their binary. So the first part in such an engagement is to create a malicious binary (an implant) that will evade security controls in the target organization. Most of red teams will have specialists for this.

The next step includes delivery of implant and execution in context of a regular, non-privileged domain user, on the workstation designated for the red team exercise. And if everything works well, we’ll get that beacon communicating to our front end servers.

What now? While there are many things we do next, such as getting some awareness about the organization, setting up persistence, trying to move laterally, there are cases when we would like to fetch the user’s password, or their TGT (Ticket Granting Ticket) for Kerberos. Some actions will not need this, as we can use the builtin Windows authentication of the process our beacon is running under, but if you want, for example, to start a SOCKS proxy and tunnel some tools from your office, we will need to authenticate to target services, and for that we will either need the user’s password, their password hash or TGT. How do we get one through our implant, considering that we do not have local administrator privileges yet?

Unconstrained delegation

Back in 2018, Benjamin Deply, the famous Mimikatz/Kekeo author published a very interesting method (https://x.com/gentilkiwi/status/998219775485661184) of obtaining a user’s TGT without requiring administrator privileges.

The trick is the following: as our implant is running under a regular user, that is already authenticated, we will abuse Kerberos GSS-API to ask for a ticket for a service, but not any service – a service that has been configured for unconstrained delegation!

The idea is the following – as we will be requesting a service ticket for a service that is configured for unconstrained delegation, the resulting response that we will receive from a domain controller will also include our own TGT. In a normal workflow, this response is converted to an application request (AP-REQ) that is sent to the target service.

AP-REQ is made up of two components: a ticket and an authenticator. We are interested in the authenticator – it is encrypted with the ticket session key which is known to us, and to the target service that we want to access. And this is were Benjamin’s great research comes into place – if we request a service ticket for a service that has been configured for unconstrained delegation, the authenticator component will contain our TGT (since the target service will need it)!

In other words, we can carve out the TGT of the currently logged in user, without needing administrator privileges! This functionality exists in Rubeus, but if you are running your Cobalt Strike implant (in SEC565 we use Cobalt Strike and Empire), it is better to use a BOF for this purpose. There are several BOF’s you can use, one I like is the tgtdelegation BOF available at https://github.com/connormcgarr/tgtdelegation

Before we start using it, one thing we did not mention is how to find a service that has been configured for unconstrained delegation. This is actually trivial as Domain Controllers are configured for unconstrained delegation by default, so we can use, for example, CIFS/domain.controller or HOST/domain.controller as target SPN’s.

The figure above shows how easy it is to fetch the TGT. You can see how the BOF displayed the AP-REQ output, extracted the session key and identified the encryption algorithm (AES256) and finally (not visible) extracted the TGT.

Credential Guard

By fetching a TGT we can now perform a number of other things, including relaying traffic through a SOCKS proxy. So in a recent engagement I tried to do this but all requests failed – every single time the response received did not contain a TGT, even though the target service indeed was configured for unconstrained delegation, and the account used was not marked as “Account is sensitive and cannot be delegated.”

In other words, we can see that the AP-REQ was indeed received, but it did not contain our TGT in the authenticator part of the response. What could cause this?

After some time and research, it turned out that the reason for this was Credential Guard, which was enabled on the client machine.

Among other (great) security features that Credential Guard brings, one thing that is important for this particular attack (or abuse) is that Credential Guard completely blocks Kerberos Unconstrained delegation, which effectively blocks us from extracting the TGT (and will break any application that relies on this feature as well!).

Besides this, Credential Guard also blocks NTLMv1 completely and there are a number of other nice security controls, as listed https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/

Test and enable!

In engagements I do I still do not see Credential Guard enabled in many enterprises. No wonder since it can break some things, however as Microsoft is now enabling Credential Guard by default in Windows 11 22H2 and Windows Server 2025, it is definitely worth checking whether your organization is ready for a wide adoption of it. It will not stop every attack, but every single step will help!

Thanks to my team members Luka, Neven, Fran and Mislav for debugging! In a RT you need a team!
 
--
Bojan
@bojanz
@bojanz.bsky.social
INFIGO IS