Episode 1: Eating Your Own Dog Food

Pure Signal Use Cases, From Team Cymru’s Security Operations Team

Introduction

Have you ever heard the phrase "eat your own dog food" - roughly translating to "use your own products"? I'll be honest with you reader, it gives me the ick. I have a dog and I've seen what he'll eat... Anyway, working in SecOps at Team Cymru is more like eating your own delicious chocolate cake. Much better, no? And here in the Pure Signal Threat Intelligence bistro, it's quite the buffet.

Gaining fast threat insights

As an amuse bouche, our Scout threat hunting tool is a great place for us to begin. Investigating an alert from your SIEM? Just enter a URL or public IP into the Scout search bar to get started. Here we have some useful information at a glance.

For instance, in the screenshot below we can see this IP is associated with the Quasar malware family.

Even better, check if your SIEM vendor has a Team Cymru Scout integration available yet! If not, you can always code your own to interact with Scout's API (read on for more).

Expanding on initial threat insights

Now for the main course.

Scout and Recon are both excellent tools for day-to-day SecOps tasks. For example, the SecOps team is often called upon to investigate suspicious emails. These emails may include URLs or attachments that need analysis, and we may find more useful information in the headers. Scout is an excellent place to start for this kind of work because it helps us focus and get fast insights, before sinking our teeth further into our investigation.

Taking what we can quickly gain from Scout, we can pivot into Recon for more detailed information if necessary. It’s good to note that Scout can look back up to 90 days, but is limited to a 30 day window to support the emphasis on speed, with Recon I can take larger bites and query across all of the available time window.

For example, to investigate attachments we can deploy Recon's malware add-on to sandbox the file (if it doesn't already exist in our extensive database of malware samples).

On a more proactive front, the SecOps team also leverages Scout and Recon for threat reconnaissance, a term we’ve coined for hunting outside your network borders. Using OSINT information gleaned from cyber news (including Dragon News Bytes - more on that later) we hunt for unusual activity involving Team Cymru public IP space.

For example, after reading about the abuse of Discord for C2 communications, we can search for comms.tag = "discord" comms.peer = "*CIDR of interest*" in Scout to identify similar traffic. If the query returns any results, we can switch to Recon for more granular information. 

To avoid drinking from the fire hose, reoccurring and multistage workflows can be automated with some scripting and the Scout API. For example, using the /scout/search API endpoint and a similar query to the one above, we can list OST (Offensive Security Tool) tagged IPs communicating with our public IP space. Our script can then query for more information about the IPs on that list using the /scout/ips endpoint. Alternatively, we could graph out the results to identify trends, as we have with scanners.

Icing on the cake

Let's finish with something sweet. Team Cymru offers a wealth of no-cost Community Services for network operators and ISPs, yet some others are for everyone that I use all the time.

Our curated cybersecurity news mailing list, Dragon News Bytes (DNB) is an excellent resource for tracking down articles with IoCs. I’m often alerted to threats I was unaware of, which makes me want to investigate and establish if Team Cymru, or one of our suppliers, is potentially going to be impacted.

I think a lot of people don’t know about our malware utility, Malware Hash Registry (MHR). It’s a neat way to enhance your malware analysis workflows without the complexity of adding multiple AV scanners. You can read more and sign up here.

Don’t forget to check out the full menu of our free-to-use Community Services here.

Conclusion

And there you have it. Remember, you don't have to work for Team Cymru to get access to all these brilliant tools (and more!) 

This is the first in the series, so I hope you enjoyed your first taste of things to come, sign up for our newsletter so you don’t miss the next blog!

A Primer for Senior Stakeholders

What is DORA (Digital Operational Resilience Act)?

The Digital Operational Resilience Act (DORA) is coming in 2025, and if your organization turns over €50m a day, the fines can exceed that alone.

For the EU lawmakers it is more than just a regulatory framework, they view it as fundamental to Europe protecting itself as a financial powerhouse —it’s a strategic mandate that reshapes how financial entities approach digital risk management. Designed to harmonize operational resilience requirements across the EU, DORA addresses the increasing interdependencies in the financial ecosystem and the vulnerabilities these connections create.

For CISOs and senior stakeholders, this regulation isn’t just about compliance; it’s about redefining resilience strategies in a rapidly evolving threat landscape.  And many aren’t yet prepared, budgeted nor capable.

This primer explores DORA’s core requirements and examines how current solutions, processes and procedures might unintentionally hinder your compliance efforts, leaving your organization exposed.

Why It Matters to CISOs: The Cost of Non-Compliance are Financial and Operational Risks

DORA’s enforcement, starting in January 2025, brings significant financial penalties for non-compliance. Beyond fines, operational inefficiencies can amplify costs, disrupt services, and erode trust.

Financial Penalties and Impact

Non-compliance with the Digital Operational Resilience Act (DORA) carries significant financial penalties that vary depending on the nature and severity of the violation. These penalties serve as a strong incentive for organizations to prioritize compliance and operational resilience.

Let’s break down the most impactful and likely.

Fines for Non-Compliance:

Financial entities that fail to comply with DORA’s provisions may face fines up to 1% of their average daily worldwide turnover for each day of non-compliance, up to a maximum of six months.

Let’s put these into real-world scenarios:

• Consider a mid-sized bank with an average daily worldwide turnover of €50 million. A breach resulting in six months of non-compliance could lead to fines of up to €300,000 per day, accumulating to €54 million—over 10% of the bank’s annual revenue

• If an insurance firm’s revenue is €25 million per day and its ICT compliance budget is €5 million annually, a month of non-compliance could result in fines exceeding €7.5 million, 150% higher than the overall budget, rendering compliance far more cost-effective.

These penalties apply to breaches such as inadequate ICT risk management frameworks, failure to report incidents in a timely manner, or insufficient oversight of third-party ICT providers.

Penalties for Critical ICT Third-Party Providers:

Critical ICT third-party service providers (CTPPs) that fail to meet DORA’s requirements can face similar fines, emphasizing the importance of robust contractual agreements and compliance with oversight frameworks.

Additional Administrative Penalties:

Competent authorities may impose additional administrative sanctions, including public reprimands, restrictions on business activities, or the suspension of licenses for persistent or severe non-compliance.

Reputational Impact

Organizational:

Under Article 54, DORA allows authorities to publish details of administrative penalties for non-compliance, potentially naming and shaming organizations that fail to meet regulatory requirements.

For CISOs, this represents a dual challenge: managing compliance to avoid financial penalties and safeguarding the organization’s reputation in the event of enforcement actions. The ripple effects of public disclosure can include loss of customer trust, weakened stakeholder confidence, and long-term financial impacts far exceeding the initial fines.

Personal:

It goes without saying that having your organization’s name exposed with you personally associated with it as a senior stakeholder position is more than embarrassing, as it causes reputational harm that impacts future career potential.  Rarely does a negative incident turn into positive PR.

Operational Impact

Beyond monetary penalties, organizations risk operational inefficiencies caused by non-compliance. These indirect costs can compound the financial impact significantly.

Operational Inefficiencies:

A lack of streamlined incident reporting or incomplete visibility into third-party vulnerabilities can inflate response times, leaving critical gaps in your resilience strategy.

Aligning with DORA’s mandates ensures your resources are invested in risk mitigation rather than post-incident recovery—a shift that directly impacts the bottom line.

The Gaps in Existing Platforms

To gain control over digital assets, many organizations rely on solutions often supplemented by manually gathered data from audits and static reports, to monitor their external infrastructure and meet compliance needs. However, these tools often fall short of DORA’s demands for precision and granularity specifically for external and third-party infrastructure, particularly for assets beyond the organization’s direct control but still within the regulation’s scope.

Common Challenges

Despite the growing sophistication of cybersecurity tools, the main challenges have three main causes:

Limited Visibility:

Platforms that rely solely on internal data or incomplete third-party inputs fail to capture the full spectrum of risks.

Inaccurate Attribution:

Generic or poorly validated intelligence can lead to false positives, diverting resources from real threats.

Static Data Models:

Tools that lack dynamic or real-time capabilities struggle to keep up with threat actor infrastructure that evolves rapidly.

How these challenges limit alignment with DORA

When looking at the outcomes of the challenges existing tools have when attempting to align with DORA, they are typically going to be as follows:

Proactive Detection:

Many solutions fail to detect and map adversary infrastructure before attacks materialize. DORA’s focus on proactive measures requires not only awareness of threats but also the ability to take preemptive actions against them. Tools that rely on static data or delayed updates cannot keep pace with the dynamic tactics, techniques, and procedures (TTPs) used by advanced threat actors.

Threat Actor Attribution:

Under Articles 19 and 20, organizations must include threat actor attribution in their incident and threat reports. However, many current tools lack the granularity needed to reliably identify and attribute activities to specific threat actors. Incomplete or inaccurate attribution can lead to regulatory scrutiny and hinder effective mitigation efforts.

Tactics, Techniques, and Procedures (TTPs):

Reporting requirements explicitly call for detailed descriptions of threat actor methodologies, including their tactics, techniques, and procedures. Generic CTI platforms often fail to provide this level of precision, relying instead on high-level summaries that offer limited actionable insights. This gap forces organizations to invest additional resources in manual analysis, which can delay reporting and divert efforts from incident containment.

Recommended Mitigations:

DORA expects reports to include actionable recommendations for mitigating identified threats. Existing tools frequently provide general advice rather than tailored, context-specific mitigations aligned with an organization’s external attack surface. This mismatch can lead to incomplete compliance and insufficient protective measures.

Integrated Insights:

Disparate tools that do not integrate external telemetry with internal data create blind spots. Without a unified view, organizations struggle to align their intelligence efforts with DORA’s reporting standards. Tools lacking comprehensive external IP visibility make it difficult to track threat actor infrastructure effectively, let alone identify systemic vulnerabilities in third-party ecosystems.

Such limitations expose organizations to avoidable risks, especially when dealing with third-party ICT providers or global supply chain networks.

Third-Party Risk Management: A DORA Priority

Third-party ICT providers represent one of the most significant sources of risk under DORA. Many financial entities struggle to maintain continuous visibility into third-party assets, often relying on contractual provisions or processes that involve manual collection and inventorying that fail to address operational realities.

Key Requirements

Discovery and Monitoring:

DORA mandates proactive identification and ongoing assessment of third-party vulnerabilities (Articles 28-30). Financial entities must continuously monitor the security posture of third-party ICT providers to identify hidden risks. This includes assessing vulnerabilities not only during onboarding but throughout the lifecycle of the relationship.

Actionable Intelligence:

Static inventories of third-party assets are insufficient under DORA’s requirements. Organizations must leverage timely and accurate intelligence to address emerging threats (Article 29). This includes dynamic insights that allow for rapid action when vulnerabilities are identified in third-party systems.

Without these capabilities, organizations risk non-compliance and operational disruptions—both of which can carry significant financial consequences, as outlined in Articles 33 and 42.

Operational Resilience: Beyond the Basics

Resilience isn’t just about surviving an incident—it’s about ensuring continuity under any circumstances. DORA emphasizes resilience testing, incident management, and recovery processes that prioritize proactive strategies over reactive measures (Articles 24-27).

What’s Missing in Current Approaches

Proactive Detection:

Being deployed on premisses, or, focussed solely on the organization as a single entity, many traditional solutions fail to detect adversary infrastructure before attacks materialize, leading to prolonged disruptions. Proactive threat identification, as required under Article 24, is essential to prevent cascading impacts.

Integrated Insights:

Disparate tools that don’t integrate to share intelligence or provide holistic views of external risks hinder effective decision-making, compromising the harmonized approach mandated in Article 26.  It is often down to the manual intervention of analysts to raise the alarm and reach out to third parties, preventing the ability to scale this to large supply chain eco-systems.

Resource Drain:

Inefficient systems bog down teams with manual processes, increasing the likelihood of compliance lapses and exposing organizations to regulatory penalties (Article 33).

DORA’s harmonized frameworks require tools and processes that streamline workflows, enabling faster and more effective responses to incidents.

Incident Reporting: Where Efficiency Meets Compliance

Reporting ICT-related incidents and cyber threats isn’t just a regulatory requirement—it’s a strategic opportunity to demonstrate control and competence. However, many organizations face inefficiencies due to outdated tools and inconsistent methodologies.

DORA’s Incident Reporting Mandates the following:

Standardization:

Organizations must classify and report incidents using standardized formats and templates, as outlined in Articles 19 and 20 of DORA. These formats are designed to ensure consistency, clarity, and efficiency in incident reporting across the financial sector.

When facing alignment with DORA, these reporting requirements can be used as a gap analysis of existing solutions, workflows, and processes you may already have in place, yet they need reviewing and potentially more investment.

Examples of Standardized Reporting Formats:

• Incident Classification Templates:

  • Categorize incidents by severity (e.g., critical, high, medium, low).

  • Include fields such as time of detection, root cause, and affected systems.

• Initial Notification Forms:

  • Require submission of essential details within a specified timeframe (e.g., 4 hours for critical incidents).

  • Mandatory fields might include the nature of the incident, suspected cause, and initial impact assessment.

• Intermediate and Final Reports:

  • Intermediate reports may include updates on containment measures, ongoing investigation details, and provisional recovery timelines.

  • Final reports should provide a comprehensive post-incident analysis, including lessons learned, long-term mitigations, and resolution status.

• Threat Notification Templates (for voluntary reporting of significant threats):

  • Focus on emerging risks with potential systemic impact.

  • Include threat actor attribution, TTPs (tactics, techniques, and procedures), and recommended mitigations.

• Cross-Sector Aggregation:

  • Where financial entities are part of a group, DORA allows for consolidated reports using a single template to streamline reporting across multiple entities.

• Electronic Submission Standards:

  • Formats such as XML or JSON for compatibility with regulatory portals and automation tools.

  • Structured fields to enable seamless integration into supervisory authorities’ incident tracking systems.

Timeliness:

Reports must be submitted within strict timelines (Article 19), requiring automated processes to ensure compliance without sacrificing accuracy.

Inefficient reporting frameworks delay compliance and increase the likelihood of regulatory scrutiny, as emphasized in Article 22. Streamlining these processes not only meets DORA’s requirements but also reinforces an organization’s resilience strategy.

For example, achieving timely threat actor attribution using finished threat intelligence reports can be a daunting challenge—if not impractical altogether. These reports frequently rely on incomplete data, placing undue pressure on your threat intelligence suppliers to investigate using fragmented information. The result? Multiple dead ends and delays that directly hinder your ability to meet reporting timelines.

Bridging the Compliance Gap with External Telemetry

DORA introduces a higher standard for operational resilience and risk management, but existing capabilities often fall short of meeting these expectations. External telemetry—particularly IP-based intelligence enriched with global visibility—is the missing link. This capability enables organizations to:

Passively monitor Third Parties for Compromise:

Ensure continuous oversight of critical ICT providers.

Proactively Block Threat Actor Infrastructure:

Mitigate risks before they escalate into incidents.

Trace Victims of Cybercrime:

Provide accurate reporting that satisfies regulatory demands and informs better protection strategies.

These capabilities are essential for addressing DORA’s requirements while reducing exposure to financial penalties and operational inefficiencies.

Closing the Gap: Strategy, Not Just Compliance

DORA represents more than a regulatory obligation—it’s an opportunity for CISOs and senior stakeholders to strengthen their organization’s resilience, agility, and overall cybersecurity posture. To turn DORA into a strategic advantage, start by evaluating current capabilities and fostering collaboration across teams impacted by its mandates.

Practical Steps for CISOs

Evaluate Current Capabilities

Engage your internal teams to assess how well your existing tools, processes, and workflows align with DORA’s requirements. Specific teams to involve include:

Security Operations Center (SOC):

Ask how effectively they detect and attribute adversary infrastructure.

Example Question: Are we consistently identifying threat actor tactics, techniques, and procedures (TTPs) in a way that informs incident reporting and mitigations?

Threat Intelligence Teams:

Assess the quality and relevance of current threat feeds and intelligence reporting.

Example Question: Do our intelligence sources provide accurate, timely threat actor attribution, or are we relying on incomplete data?

Third-Party Risk Management:

Review how third-party risks are currently identified and managed.

Example Question: Do we have visibility into the external infrastructure of our critical ICT suppliers, and how quickly can we detect vulnerabilities or breaches in their systems?

Identify Key Collaborators

DORA impacts multiple areas of your organization, requiring cross-functional alignment.

Start collaborating with:

IT and Infrastructure Teams:

To ensure ICT systems and backup protocols meet resilience testing requirements.

Legal and Compliance Teams:

To confirm contracts with ICT third-party providers include provisions required by DORA.

Procurement Teams:

To vet and manage critical ICT suppliers, ensuring they align with DORA’s oversight standards.

Regulatory Reporting Teams:

To streamline reporting workflows and ensure templates and timelines align with Articles 19 and 20.

Establish Priorities and Invest Strategically

Use DORA’s framework as a lens to identify high-priority gaps and allocate resources effectively. For example:

Invest in tools that offer real-time external threat intelligence to improve incident detection and reporting accuracy.

Automate processes where manual workflows create bottlenecks, particularly in threat intelligence analysis and incident reporting.

Conduct table-top exercises to simulate DORA-specific scenarios, such as supply chain compromises or ICT failures, and measure response effectiveness.

Foster a Culture of Continuous Improvement

Ensure your teams are not treating DORA compliance as a static goal but as an ongoing process. Encourage regular reviews of ICT risk management practices and collaboration with other financial entities to share lessons learned and best practices.

By actively engaging teams, asking the right questions, and fostering cross-functional collaboration, CISOs can turn DORA compliance into a foundation for long-term operational and strategic resilience.

Frequently Asked Questions (FAQs)

What does DORA stand for?

DORA stands for the Digital Operational Resilience Act.

What is DORA regulation about?

DORA is an EU regulation designed to ensure that financial entities, including banks, insurance companies, and investment firms, can withstand and recover from severe ICT (Information and Communication Technology)-related disruptions. It harmonizes operational resilience requirements across the EU financial sector.

Is there a UK equivalent of DORA?

While the UK does not have an exact equivalent to DORA, similar regulatory frameworks exist, such as the Operational Resilience Rules introduced by the Bank of England, Prudential Regulation Authority (PRA), and Financial Conduct Authority (FCA).

Who is exempt from DORA?

Micro-enterprises and smaller financial entities may qualify for a simplified ICT risk management framework under DORA, as outlined in Article 16. However, critical financial entities and ICT third-party providers are not exempt.

What contracts does DORA apply to?

DORA applies to contracts between financial entities and ICT third-party service providers. It mandates specific provisions for monitoring, oversight, and risk management, ensuring that third-party providers comply with resilience requirements (Articles 28-30).

What is DORA used for?

DORA is used to standardize the management of ICT risks, establish incident reporting requirements, oversee third-party ICT service providers, and ensure operational resilience testing within the financial sector.

What is JA4+ and Why Does It Matter?

Introduction

Threat analysts and researchers are continually seeking tools and methodologies to gain a clearer understanding of malicious activity. JA4+ is an innovative approach designed to enhance network traffic analysis and infrastructure characteristics, enabling security professionals to identify and respond to threats more efficiently.

For CISOs and organizational leaders, for your security teams, JA4+ represents a significant advancement in providing actionable insights while supporting the operational goals. This primer aims to explain the value of JA4+, delve into its functionality, and highlight its relevance to both analysts and researchers.

What is JA4+?

JA4+ is the collective name for a broad suite of network fingerprinting methods, which are designed to facilitate threat hunting, network characterization, and advanced traffic analysis. These techniques help security teams identify patterns and behaviors in encrypted and unencrypted traffic, enabling the detection of malicious activity or unusual behavior based on specific attributes.

Think of JA4+ as a collection of tools that recognize unique "handshakes" or interactions that different software, devices, or threat actors use when communicating online. This makes it possible to analyze traffic in greater detail—even when the content of communications is obscured by encryption, designed to uncover hidden patterns and behaviors in network communications.

The JA4+ suite enables analysis of everything from encrypted traffic, like TLS and SSH, to web activity and digital certificates, providing insights into both client and server interactions. It even measures timing between systems to detect anomalies and actively scans connections for unique identifiers. Together, these techniques give security teams a clearer view of network activity, helping them detect and investigate threats more effectively.

Both JA3 and JA4+ were created by John Althouse (Medium page here) and a team of passionate developers looking to solve the investigation and research challenges they saw.

For this primer, we’ll focus specifically on JA4 method of fingerprinting TLS (Transport Layer Security) client libraries based on the ClientHello packet during the initial handshake. This technique allows analysts to identify specific applications or malware communicating over TLS by analyzing unique attributes from this handshake process.

The Benefits of JA4

JA4 offers several key advantages that make it an essential tool for traffic analysis and threat detection:

John lists the primary advantages over JA3 as follows:

• JA4 is now both human and machine-readable, so an analyst familiar with JA4 fingerprints can simply glance at one to get a good understanding of what's going on and if it looks unusual.

• JA4 is designed to work with multiple protocols including QUIC, TLS over UDP, and DTLS.

• JA4's delimited sections make it easy to investigate or ignore particular sections of a fingerprint as well as extensible so that JA4 can be extended in the future without invalidating previous fingerprints.

• JA4 is actively maintained by FoxIO with an extensive and growing database of fingerprints freely available on ja4db.com.

What this leads to for analysts is:

• Improved Accuracy: By capturing more nuanced fingerprints, JA4 enables a higher degree of precision in identifying malicious actors and anomalous traffic.

• Enhanced Visibility: Analysts can uncover activity that might otherwise blend into the noise of encrypted traffic.

• Scalability: JA4 integrates seamlessly into existing workflows, making it adaptable for organizations of all sizes.

• Efficiency in Investigations: Faster identification of malicious entities reduces time spent on triage and analysis.

JA4 vs. JA3: What Sets It Apart?

While JA3 laid the groundwork for TLS fingerprinting, JA4 introduced several enhancements.  It builds on the principles of JA3—a technique that fingerprints the TLS ClientHello by hashing specific fields—but focuses on unique variations that improve precision in identifying threats. JA4 refines this approach, addressing some of the gaps in existing methodologies while providing enhanced utility for modern threat landscapes.

• Deeper Insights: JA4 captures additional details from the handshake process, offering a richer dataset for analysis.

• Refined Fingerprints: By addressing limitations in JA3’s methodology, JA4 improves accuracy in distinguishing between benign and malicious traffic.

• Broader Applicability: JA4 is designed to align better with modern encryption protocols and evolving threat tactics.

How JA4 Helps Analysts and Researchers

For analysts and researchers, JA4 is a game-changer in threat intelligence, offering unparalleled visibility into network activity. While JA4 often identifies the underlying libraries used to build malware—rather than the malware itself—its precision in detecting malicious behaviors remains a critical advantage.

Here’s how JA4 and the broader JA4+ suite can be applied effectively:

Unmasking Malware Traffic: By leveraging JA4 fingerprints, analysts can detect specific tools or libraries that malware relies on, even when adversaries attempt to obscure their activity with encryption. The JA4+ suite reduces false positives by combining multiple fingerprints—up to 7 per connection—to ensure high-fidelity identification of malware or applications.

Behavioral Analysis: JA4 enables analysts to associate unique fingerprints with specific adversary behaviors, offering deep insights into how threat actors operate.

Threat Hunting: The combination of JA4+ fingerprints allows analysts to proactively identify suspicious patterns in network traffic, reducing dwell time for threats and improving detection accuracy.

In some cases, JA4 alone can be the "silver bullet" that unmasks malware with stunning precision

Example Use Case:

A malware sample uses a unique JA4 fingerprint during its encrypted communication with a command-and-control server. Analysts can flag and track this fingerprint across their network, identifying other compromised systems or attempts at infiltration.

Technical Overview: Understanding JA4

JA4 works by hashing specific fields from the TLS ClientHello message, such as:

• Cipher suites

• Extensions

• Signature Algorithms

• Other handshake attributes

These hashed fields create a unique identifier or "fingerprint" that can be matched against known malicious or benign traffic patterns. JA4’s refined approach allows it to capture subtler variations, making it particularly effective in identifying evolving threats.

Unlike JA3, which may occasionally group benign and malicious traffic under the same fingerprint, JA4 introduces additional granularity, reducing false positives and improving detection rates.

Conclusion: A Powerful Tool for Threat Analysts

JA4 is more than just an evolution in TLS fingerprinting—it’s a crucial asset for any security team seeking to strengthen its investigative capabilities. By providing precise, actionable insights into encrypted traffic, JA4 empowers analysts to stay ahead of adversaries and protect their organizations more effectively.

JA4 is set to become an indispensable part of the threat intelligence toolkit, with support from major platforms like CloudFlare and AWS.

Stay tuned for further updates as we continue to advance the capabilities of the cybersecurity community.