Month: February 2026

Episode #65 Andrew Cook from Recon Infosec discusses Incident Response and Threat Hunting

Original Entry by : Michael Morris

In the Packet Forensic Files, Episode 65, Michael talks to Andrew Cook, CTO at Recon InfoSec and host of the Thursday Defensive Webcast.

By Michael Morris, Senior Director of Global Business Development, Endace

Michael Morris, Director of Global Business Development, Endace

The Increasing Complexity of Incident Response
and Threat Hunting

In this episode of The Packet Forensic Files, I’m joined by Andrew Cook, CTO of Recon InfoSec – an Air Force cybersecurity veteran and seasoned DFIR expert – to discuss what it really takes to investigate and respond to today’s most complex cyber incidents.

Drawing from his years of frontline experience handling major breaches and ransomware events, Andrew shares how real-world incidents have reshaped his investigative mindset. One area he starts with is the “human impact” of working through a security incident.  Cyber breaches have impacts on people who may experience guilt for having been the one who clicked on that phishing email, or anxiety and stress for the people who are trying to quickly defend, investigate, and remediate a breach to get their company back online.  Their experiences are not unlike those of crime victims on the street. Or first responders facing high-pressure situations.

We walked through Andrew’s incident response workflow, focusing on the steps he considers most critical when time, clarity, and confidence are most important. He talks about the importance of “timelining” to accurately build a timeline of evidence, events, and data to fully understand the breadth and depth of a breach.

Andrew shares some of his tools of choice for incident response investigations when he doesn’t have the luxury of his company’s full security stack. He gives examples of how packet data, when combined with endpoint logs, SIEM alerts, and threat intelligence, enables investigators to build a far more complete and defensible picture of incidents. Packet-level visibility, in particular, remains a cornerstone of high-fidelity investigations—often revealing attacker behavior, lateral movement, or data exfiltration activity that traditional logs and other telemetry may miss.

We also explored how different types of incidents should be prioritized and categorized to ensure the right resources are applied at the right time. Andrew highlighted the need for clear decision-making frameworks that balance technical severity, business impact, and regulatory considerations.  He talks through the concept of thinking about the potential risks and thinking backward from that outcome of what would be needed to prevent or solve that problem as you build and design your SOC architectures.

Looking ahead, Andrew shares his perspective on emerging trends shaping digital forensics and incident response, including the increasing sophistication of adversaries, growing data volumes, and how leveraging AI can help SOC analysts make sense of the complexity. Ensuring forensic rigor while meeting regulatory and legal requirements remains a non-negotiable aspect of modern DFIR work.

Finally, Andrew shares what he thinks is key to look out for over the next 6–18 months: Attackers using AI-assistance to leverage threat vectors – for example using application extensions – that drive data loss. And AI plugins given access to sensitive data that are leveraging prompt injections and PowerShell programs to compromise environments.  The sophistication of threat actors with the help of AI is only getting more advanced.

PFF Ep 65 Andrew Cook, Recon Infosec

Other episodes in the Secure Networks video/audio podcast series are available here. Or listen to the podcast here or on your favorite podcast platform.

Cisco Live Amsterdam 2026: IPv6’s Time is Finally Here, for Users and Threat Actors Alike

Original Entry by : Cary Wright

By Cary Wright, VP Product, Endace

Cary Wright, VP Product Management, Endace

Cisco Live Amsterdam 2026: IPv6 is finally here, along with the threats

At each SOC event, we capture and inspect every packet from start of show through to the very last hour, for the purpose of securing the attendees and conference, wiping the data at the end. This gives us a rare opportunity to understand how the traffic trends and threat landscape are changing. Each SOC event shows us new data and developing trends that are useful to dig into. The week of Cisco Live EMEA, we got to see a milestone with the transition to IPv6.

The Internet has technically been out of IPv4 addresses for years, yet global adoption of IPv6 — the modern protocol designed to replace it — continues to climb slowly. As of late 2025, worldwide IPv6 usage sits at roughly 49%, based on Google’s traffic metrics.  While several countries have made remarkable progress, the global transition remains uneven and far behind early expectations.

Why IPv6 Matters

IPv4’s roughly 4.3 billion available addresses are nowhere near enough for today’s hyper‑connected world. In contrast, IPv6 offers a 128‑bit address space, providing 3.4 x 1038 possible addresses — more than enough for decades of growth.  Technologies like Network Address Translation (NAT), private addressing, and CIDR have extended IPv4 far beyond its natural lifespan. These workarounds give organizations a false sense that IPv4 is still sufficient, reducing the urgency to adopt IPv6.

What we observed in Amsterdam

In the Cisco Live EMEA SOC, we inspected 130 billion packets across 32,434 unique IP endpoint devices at the conference, using Splunk to query unique DHCP Client IDs to measure. These included devices connecting to the Wi-Fi and wired networks at the Cisco Live conference network, including attendee laptops, phones, and conference devices such as demo stations, cameras, IOT devices, displays, networking equipment, and any other IP connected device.

Of this traffic, 62% of the data travelled over IPv6, and only 38% over IPv4. This represents a tectonic shift in the move to IPv6. Perhaps this was because we were sitting just a few miles from the Regional Internet Registry for Europe, Middle East and Central Asia (RIPE NCC), or more likely this is because the world is finally ready and moving to IPv6.

Our heaviest day was Tuesday, with 25,609 devices that connected to the network.

Across all this traffic we observed 1.7 million unique IP addresses, most of which were external addresses accessed by attendees and conference devices. Those IP addresses were made up of 386,397 IPv4 addresses, and 1,339,329 IPv6 addresses.

Threat Actors — adopting IPv6 faster than anyone

In the SOC, we have no shortage of data to interrogate, interrogating our Splunk data highlight that threat actors are now heavily favoring IPv6 to conduct their attacks, hijack resources, or compromise systems.  Over 99% of malicious URLs and crypto miners used IPv6, telling us that we need to ensure we properly secure our IPv6 infrastructure. Just 1% of our attacks involved IPv4. That indicates a trend that we all need to take notice of.

Splunk search of incidents at Cisco Live EMEA 2026
A Steady Shift — But an Inevitable One

Although the transition has taken decades, IPv6 momentum appears to have crossed an important threshold. With increasing digital demands, rising IPv4 costs, and rapidly expanding device ecosystems, IPv6 isn’t just beneficial — it’s essential.

The future of the Internet is unquestionably IPv6. The challenge now is how quickly the world can get there, and how well we secure it. At Cisco Live EMEA, we saw the world has taken a large and important step forward.

Acknowledgements

This important insight to IPv6 adoption would not have been possible without the great work done by the Cisco Live EMEA SOC team, led by Jessica Oppenheimer and Ivan Berlinson.

Data collected and analyzed was the result of a team, many thanks go to the following team members:

Network Operations Center Liaisons

Cisco Security and Splunk SOC Team

Endace SOC Team

Read related Cisco Team Blogs from the Cisco Live Europe 2026 SOC: 
https://blogs.cisco.com/security/emea-soc-2026

For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/ 

Event SOC Website 
Visit Cisco’s Event SOC website for full details of the SOC setup, and download the whitepaper written by Jessica Oppenheimer:
https://www.cisco.com/site/us/en/products/security/event-soc-report.html

Cisco Live Amsterdam 2026: Back in the SOC after a 10-year hiatus

Original Entry by : Owen Gallagher

By Owen Gallagher, Senior Sales Engineer, Endace

Overview

This year, I had the opportunity to work in a Security Operations Centre (SOC) for the first time in over a decade, at Cisco® Live Amsterdam. I joined the team responsible for monitoring and responding to incidents on the public Wi‑Fi network.

Cisco builds a fully operational SOC at each Cisco Live event, using tools from Cisco, Splunk and Endace to secure the environment. The team is a mix of engineers and analysts from all three companies, with experience ranging from first‑time responders to L3 (also known as Tier 3) analysts. Even though many of us had never worked together before, the teamwork was excellent. Everyone shared knowledge, helped each other understand different technologies and supported one another during investigations.

Because this was my first SOC shift in over 10 years, it took a little time to get into the rhythm of moving from a Cisco XDR Incident notification, gathering evidence, and deciding whether to close or escalate an incident. But after working through a full investigation, things started to click again.

One incident in particular stood out, so I’ll walk through the workflow and how we reached our conclusion.

The Notification

Cisco XDR® reported suspicious activity: a suspicious IP response from an external host. My first task was to understand what this external IP address was and which internal devices it had communicated with on the Wi‑Fi network. The screenshots below show how the alert appeared in Cisco XDR, including the details provided in the incident description.

Identifying the External IP

I used Talos® Intelligence to look up the IP address. Talos showed that the IP was untrusted and already on the block list, which immediately made the incident more important to investigate.

Checking Internal Communication

Next, I moved into Splunk®. By filtering logs from the Cisco Secure Firewall® (running in passive mode), I could see that the suspicious IP had communicated twice with two internal assets. Based on the address range, these devices were on the wireless network.

The logs also showed that, if the firewall had been in active mode, this traffic would have been blocked. The protocol involved was ICMP, meaning these were ping requests.

At this point, I knew what happened and which devices were involved. But I still needed to confirm whether the pings were successful and what the actual packets looked like.

Verifying with Packet Capture

To answer those questions, I turned to Endace, which records all network traffic. Using EndaceVision™, I generated a visualization that showed two 64‑byte packets exchanged between the external IP and the two internal devices. This matched what Splunk was showing.

To dig deeper, I pivoted into Wireshark™, hosted on EndaceProbe™, to inspect the raw packets. Wireshark confirmed two‑way ICMP communication, which gave us the evidence we needed to document the incident accurately

Escalation

I gathered screenshots, packet details and log information and documented in my report in the  XDR Incident Worklog. Because this was confirmed communication with an untrusted IP, I escalated the incident to the network team for a perimeter firewall review and to ensure that the IP address was added to the block list. 

Final Thoughts

This incident reminded me how important full packet capture is. Logs show that something happened, but packets tell you exactly how it happened and give you the confidence to take the right action.

Working in the Cisco Live SOC after so many years away from this environment was a rewarding experience. The collaboration, the technology and the live investigations made it a great week, and it reinforced why SOC work is so valuable: you get to protect real users in real time and understand the network at a level you can’t get anywhere else.

Acknowledgements

My experience at this event would not have been possible without the great work done by the Cisco Live EMEA SOC team, led by Jessica Oppenheimer and Ivan Berlinson.

Data collected and analyzed was the result of a team, many thanks go to the following team members:

Network Operations Center Liaisons

Cisco Security and Splunk SOC Team

Endace SOC Team

Read related Cisco Team Blogs from the Cisco Live Europe 2026 SOC: 
https://blogs.cisco.com/security/emea-soc-2026

For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/ 

Event SOC Website 
Visit Cisco’s Event SOC website for full details of the SOC setup, and download the whitepaper written by Jessica Oppenheimer:
https://www.cisco.com/site/us/en/products/security/event-soc-report.html

Cisco Live Amsterdam 2026: Malicious trojan file sent over POP3 email

Original Entry by : Sundarram Paravastu

Sundarram Paravastu, Principal Software Engineer, Endace

Overview

At each Security Operations Center (SOC) event, we capture and inspect every packet from start of show through to the very last hour, for the purpose of securing the attendees and conference, wiping the data at the end.

We had two of Endace’s newest EP94C8 EndaceProbes™ doing full packet capture providing unique insight into all activity on the network, delivering critical context and evidence for Incident Response and Threat Hunting teams. As part of the setup, we also had Application Dock VMs running on the EndaceProbes, extracting files where possible from unencrypted traffic, and sending rich metadata and Zeek® logs to Splunk® and Splunk Attack Analyzer®.

Stats

Count

Total files extracted

1,743,259

Total files submitted for malware analysis

55,939

Top extensions of files submitted

.xz, .gz, .pptx, .zip, .vnd, .pdf

Files extracted from email (POP3, IMAP etc.)

887

As part of SOC, we extracted more than 1.7M files and many of them were filtered out based on a known benign file list or excluded if they were duplicates of files already submitted. Within the files that were submitted, there were many files that were extracted from HTTP, POP3, IMAP etc.

Incident example: Malicious trojan file sent over email to compromise user system

There were 70+ users using POP3 emails and all their communication was in the clear. It’s worth noting that the SOC already has Splunk automation in place (using logs submitted to Splunk by EndaceProbe-hosted VMs) that notify affected users via email that their communications are using protocols (like POP3, IMAP) that expose their credentials.

In this specific incident example, we went looking for .rar files that were extracted and submitted to Splunk Attack Analyzer. Malicious .rar files have some notoriety so it was natural to look for any potential anomalies. As it turned out, there was indeed an email attachment that had malicious files in it.

The example above had a trojan file inside the archive, that was flagged as malicious.

We now had to trace that file extracted back to the user and their IP addresses for further analysis. Looking into Splunk’s file submission log, we could narrow down the hosts responsible for sending the email:

Digging further using the packet data recorded by our EndaceProbes, we were able to access all that affected user’s POP3 traffic over the two days of the conference and review it.

We analyzed the actual PCAP data related to these POP3 sessions using Wireshark™ – hosted on EndaceProbes – to find the user related to the event.

We then extracted all the files related to those POP3 sessions so they could be submitted to Splunk Attack Analyzer for further analysis.

We did not find further malicious files sent to the user other than the one we had originally found. However, some of the links in the emails were flagged as suspicious.

In this incident, we not only analyzed the files extracted at the time of capture but were also able to retrospectively get all related packets and extract all files related to the host involved in this incident. This enabled us to do very comprehensive, and conclusive, incident analysis.

Acknowledgements

This would not have been possible without the great work done by the Cisco Live EMEA SOC team, led by Jessica Oppenheimer and Ivan Berlinson.

Data collected and analyzed was the result of a team, many thanks go to the following team members:

Network Operations Center Liaisons

Cisco Security and Splunk SOC Team

Endace SOC Team

Read related Cisco Team Blogs from the Cisco Live Europe 2026 SOC: 
https://blogs.cisco.com/security/emea-soc-2026

For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/ 

Event SOC Website 
Visit Cisco’s Event SOC website for full details of the SOC setup, and download the whitepaper written by Jessica Oppenheimer:
https://www.cisco.com/site/us/en/products/security/event-soc-report.html

Cisco Live Amsterdam 2026: First Time in a SOC

Original Entry by : Sam Brockelsby

By Sam Brockelsby, Senior Software Engineer, Endace

Sam Brockelsby, Senior Software Engineer, EndaceOverview

This year, I got my first taste of what it’s like to be part of the Security Operations Center (SOC) team working at Cisco Live® Europe 2026 in Amsterdam. The SOC team is responsible for analyzing and determining the appropriate response for various security incidents on the public Wi-Fi network for the Cisco Live event. This includes everything from relatively harmless port scanning to command-and-control attempts from malicious entities.

Coming into the SOC as a newbie was exciting and a little bit daunting. There were a lot of people to meet and a lot of new things to learn. At first, I found myself a little overwhelmed getting to grips with all the various tools, technologies and processes – fortunately, everyone on the team was incredibility supportive, open to questions and eager to help out.
As a result, I was able to get up and running within a couple of hours and escalated my first incident before lunch on the first day. I will walk through this incident in the next section.

Incident Example: Authentication Bypass Attempt

Cisco XDR® had raised an incident for an Authentication Bypass Attempt. XDR is a tool that was used in the SOC to report incidents and provide a structure to the subsequent investigation. It has powerful automated features that allow an analyst to quickly pivot into other tools such as Splunk® and EndaceProbe™. Think of it as the glue that pulls all the various tools we used in the SOC together.

In my example, the incident was detected by the Cisco Secure Firewall® via Splunk SIEM. This incident involved two endpoints on the network that were communicating with several other devices.

The detail provided by XDR told me that a number of these Authentication Bypass events had occurred since the start of the day. It also told me that the devices were all PTZOptics VHD PTZ Cameras. This suggested that there were camera systems at the event that were vulnerable.

The next step was to look at the packets. From XDR I was able to click on a Pivot-to-Vision™ link to our EndaceProbes for one of these events. Two EndaceProbe appliances captured all the traffic on the public Wi-Fi network for the event – more than 120TB of data across four days. This is invaluable for the SOC, since it guarantees that an analyst can always go back and look at the exact packet data for any given security incident.

The Pivot-to-Vision link generated an EndaceVision™ investigation on the EndaceProbes with an IP filter for the endpoint I had selected in XDR, for a 10 minute time window around the detected event in question.

EndaceVision has various tools to help understand the nature of captured traffic. In my case the Traffic Breakdown chart showed that there was a lot of http_video traffic present in my selection. This was of no interest to me, so I added an application filter to omit it from my investigation. I then launched hosted Wireshark™.

In Wireshark I applied some filters to search for POST requests to the login endpoint. I then inspected the resulting conversations between the endpoint and the other devices on the recording subnet. The conversations were unencrypted over HTTP and clear text credentials were visible.

At the very least then, we had unencrypted traffic on the network that exposed login credentials. In addition to this though, the username and password looked a bit odd to me, so I did a quick Google search on the PTZOptics VHD PTZ Camera. It turns out that these cameras have a CVE where they come configured with default hardcoded credentials that cannot be modified by the user. These default credentials can be easily found by anyone on the web, and so even if the camera operators fixed the unencrypted traffic problem, they would still be vulnerable.

The final step in the process was to escalate the issue up the chain to the Network Operations Center, with the recommendation that the camera operator take steps to encrypt the traffic and update firmware to the latest version, which patches the CVE.

Final Thoughts

Working in the SOC is a collaborative process. For this incident (and others I worked on), I needed to ask for help on numerous occasions. The SOC team we had in Amsterdam was a diverse group of people with expertise in different areas, and each person brought something unique to the table. No one has every answer to every problem, so it’s a given that you will need to ask someone else to give you a hand at some point.

For that collaboration to work though, you need to have the right kind of environment – one that challenges people to do their best, while at the same time encouraging people to speak up and ask questions free from judgement. In my experience, we got that balance right.

Acknowledgements

My experience at this event would not have been possible without the great work done by the Cisco Live EMEA SOC team, led by Jessica Oppenheimer and Ivan Berlinson.

Data collected and analyzed was the result of a team, many thanks go to the following team members:

Network Operations Center Liaisons

Cisco Security and Splunk SOC Team

Endace SOC Team

Read related Cisco Team Blogs from the Cisco Live Europe 2026 SOC: 
https://blogs.cisco.com/security/emea-soc-2026

For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/ 

Event SOC Website 
Visit Cisco’s Event SOC website for full details of the SOC setup, and download the whitepaper written by Jessica Oppenheimer:
https://www.cisco.com/site/us/en/products/security/event-soc-report.html