GitLab’s audit logs offer a goldmine of insights into user activity, project changes, and security events. Getting that data into Graylog for centralized analysis is easier than you might think—especially with the flexibility of our Raw HTTP input and Illuminate’s GitLab Spotlight Pack. In this two-part guide, we’ll walk you through how to get it done, from wiring up GitLab’s Audit Event Streaming to visualizing enriched events in a purpose-built dashboard.

Part 1: Setting Up the Raw HTTP Input for GitLab

GitLab supports Audit Event Streaming to HTTP destinations, which means we can stream logs directly into Graylog—no custom code or forwarding agents required. All we need is a properly configured Raw HTTP input and a few settings on the GitLab side.

Prerequisites

Before diving in, make sure you have:

• A valid GitLab account with permission to configure audit streaming.
• A Graylog instance with a Raw HTTP input configured and reachable from your GitLab instance.

Note:
Want to use local install of GitLab, follow GitLab click here
Want to use Cloudflare Logpush click here

Step-by-Step: Configure GitLab to Stream Logs

Start in GitLab:

• Destination Name: Pick something recognizable like graylog-audit-stream.
• Destination URL: Use the public-facing address for your Graylog Raw HTTP input—e.g., https://your-graylog-server.example.com/raw.
• Custom Headers: Match the header name/value pair defined in your Graylog input config to help secure the stream.
• (Optional) Event Filtering: Depending on your use case, you can control which types of audit events are sent.

Step-by-Step: Configure the Raw HTTP Input

In Graylog, head to System > Inputs and launch a new Raw HTTP input. Key settings include:

• Bind Address & Port: Ensure it’s reachable by GitLab.
• Authorization Header: This should match the custom header GitLab sends—name and value.
• TLS: GitLab requires HTTPS, so either enable TLS or route through a proxy/gateway that handles it.
• Enable Bulk Receiving: This is essential. GitLab sends log batches, so this must be checked to parse them correctly.

You can keep most other input settings at their defaults unless your environment requires something specific.

Part 2: Enriching GitLab Logs with Illuminate

Now that your logs are flowing, let’s make them useful. The GitLab Content Pack—available to Enterprise and Security customers using Illuminate—helps parse GitLab’s structured log data and aligns it with the Graylog schema for analysis and correlation.

What’s Included?

This pack gives you:

• Field parsing rules for all known event_types
• Schema-compatible enrichment
• Three dashboards:
  • Events Overview
  • User Overview
  • Web Overview
    

Requirements

• Graylog 6.1.3 or later
• Graylog Enterprise or Security license
• GitLab v17.9
• Raw HTTP input (dedicated to GitLab logs)

Setup Instructions

1. If not already done, set up a dedicated Raw HTTP input for GitLab logs.
2. In GitLab, configure Audit Event Streaming to use this input as a destination.
3. In Graylog:

• Navigate to the input and click Show received messages.
• Copy the gl2_source_input value (you’ll need this in a moment).
• Go to Enterprise > Illuminate > Customization.
• Edit the lookup_adapter_input_routing
• For content_name, enter the input ID you copied.
• For input_id, enter gitlab.

That’s it! Your logs are now parsed, enriched, and routed through Graylog’s schema.

Heads-up: GitLab logs contain both standard and custom fields. Fields not defined in the schema will be prefixed with “vendor_“.

Dashboards In This Spotlight

Once the content pack is configured, you can view GitLab data across three dashboards:

• GitLab Events Overview – Events across your environment

• User Overview – Activity by user

• Web Overview – Web-based audit activity

They’re plug-and-play—and fully customizable if you want to tailor them for your team.

Ready to Centralize GitLab Logs?

If you’re already using Graylog, this integration is a low-lift way to bring GitLab logs into the same workflows you use for threat detection, investigations, and compliance. And if you’re not using Illuminate yet—let’s talk. This kind of parsing power is what makes Graylog truly operational for DevSecOps teams.

In many sports, but especially soccer, a team has a set of offensive players and defensive players. The offensive players look for ways to compromise the opposing team’s defenses, seeking to get the ball in the goal. Meanwhile, the defenders work hard to push back against the opponent’s offensive line to clear the ball from the goal line.

On a security team, your defenders are the blue team. These are the security analysts who understand how to use your defensive security tools to mitigate the risk that threat actors can compromise your systems. Much like soccer players, your blue team needs to practice their skills and fine-tune their tools so that they can effectively and efficiently detect and respond to threats.

To improve your security, blue team exercises that help identify weaknesses and gaps across processes and tools.

Why Have a Blue Team?

A blue team is the shorthand name for the group of security analysts that defend the organization against cyber attacks. The blue team ensures that security controls work as intended. The blue team’s responsibilities typically include:

• Assessing security risk
• Monitoring for vulnerabilities
• Building threat detections
• Providing cyber hygiene training
• Responding to incidents

In addition, they are the analysts responsible for threat detection and incident response activities including:

• Detecting threats by creating high-fidelity alerts
• Investigating incidents by looking for indicators of compromise(IoCs)
• Mitigating and containing threats by engaging in activities like isolated infected devices, blocking malicious traffic, or terminating access for compromised accounts
• Eradicating threats by removing malware or backdoors and collecting forensic evidence from affected systems

What skills does a blue team need?

To be a blue team member, you need a range of skills across different security tools and control categories.

Network security

For companies that have a complex, interconnected, cloud-based environment, network security is increasingly important to defending against threat actors. Blue teams need to implement, enforce, and monitor different defensive controls to identify potential system vulnerabilities.

Understanding and applying threat intelligence

Blue teams use threat intelligence to anticipate and mitigate potential attacks. Threat intelligence provides insight into real-world attacker activities and IoCs so defenders. Typically, this information enables blue teams to take proactive steps to reduce risks arising from emerging threats or malicious actors targeting vulnerabilities.

Proficiency with security tools

Blue teams typically need to understand how to use security information and event management (SIEM) tools so they can create detections and security alerts. Additionally, they need to learn how to use and understand data generated by:

• Endpoint Detection and Response (EDR) tools for understanding threats to devices, like malware and ransomware
• Firewalls to control inbound and outbound network traffic
• Vulnerability scanners to identify security issues in operating systems, software, and firmware
• Network protocols for traffic analysis

Incident response

Blue teams need experience with detecting, documenting, and containing threats coming from unauthorized access to systems. Typically, they use simulations so they can practice:

• Communication and escalation skills
• Refine response processes
• Educate stakeholders, including senior management

What are the benefits of blue teaming?

Blue team exercises enable security analysts to enhance defensive capabilities by practicing cyber threat detection, response, and remediation skills. By simulating real-world attack scenarios, participants gain proactive threat awareness, allowing them to anticipate and prepare for potential threats.

Some primary benefits of blue teaming include:

• Real-World Readiness: Through practical incident response drills, teams are trained to efficiently handle actual cyber defense situations.
• Skill Gap Identification: These exercises highlight areas needing further development, ensuring team members receive the necessary training.
• Improved Operational Efficiency: They refine processes and encourage strong collaboration and communication among incident response teams.

What are blue team exercises?

Blue team exercise is the name of the simulated real-world attacks that give security teams experience defending their IT infrastructure in a safe environment.

The key aspects of blue team exercises include:

• A safe environment, sometimes using a specially designed cyber range.
• Simulated attack actions, typically mapped to adversary tactics, techniques, and procedures (TTPs) like those listed in the MITRE ATT&CK framework.
• Reviewing detections and alerts to ensure they adequately identify threats.
• Following incident response processes to test whether they work efficiently and effectively.

What is the difference between a blue team and red team in cybersecurity?

While your blue team acts as defenders, your red team tries to identify vulnerabilities, acting like attackers. The key differences between the two teams are:

• Main purpose: Blue team works on detecting and responding to threats while the red team simulates attacks to find weaknesses.
• Activities: Blue team monitors networks and mitigates attacks while the red team uses hacking techniques to breach systems
• Objective: Blue team works to strengthen the organization’s security measures while the red team works to test and exploit security gaps.
• Environment: Blue team works with real-time incident response tools to ensure they detect and alert on threats as intended while the red team uses a simulated, controlled sandbox so that their activities don’t disrupt business operations.

Why is it important for blue and red teams to work together?

Since red and blue teams manage the flip sides of an organization’s security coin, their collaboration enables the organization to have a well-rounded view of its security posture. This collaboration, often called purple teaming, provides insights as the red team tries to break into sensitive systems while the blue team works to keep them out.

By collaborating, the two teams improve the organization’s security and compliance posture. Most compliance frameworks and mandates include requirements about testing defenses and running tabletop exercises. Since the teams work in a controlled, low-risk setting, their collaboration enables them to identify potential security gaps and fine-tune security tools. Some benefits of this collaborative approach include:

• Improved Detection: Faster response times to suspicious activity.
• Enhanced Skills: Builds expertise in recognizing indicators of compromise.
• Strengthened Defenses: Identifies and addresses vulnerabilities.

Graylog Security: The Easy-to-Implement Blue Team SIEM

Graylog Security is the SIEM that security teams need without requiring them to make difficult decisions between usability, cost, and effectiveness. Graylog enables your team to maximize productivity while minimizing complexity, providing an intuitive UI and automation. With less daily manual effort, you can achieve your security objectives without guessing.

Our risk-based alerting enables you to focus on high-impact threats while our automated investigations enable you to respond to incidents faster. With our Threat Campaign Mapping, you can connect isolated alerts into full attack stories, enabling you to gain faster insights when threats attempt to compromise systems.

To see how Graylog Security gives you the SIEM that never asks you to compromise, contact us today.

Data lakes have evolved. Once treated as passive storage archives, they’re now becoming active components of enterprise risk management. The driver? Selective retrieval — the ability to park large data volumes in cold storage and later retrieve targeted slices for forensic or compliance needs.

This shift matters. According to 2025 data from Cybersecurity Insights Group, 73% of enterprises report that SIEM ingestion costs are limiting their real-time analysis capacity. At the same time, 62% of security leaders say forensic readiness is a top priority for compliance and post-incident response.

Here are five ways selective retrieval strategies are helping CISOs address both challenges without sacrificing visibility.

5 Selective Retrieval Strategies in Action

1. Focus Real-Time Analytics on High-Signal Data

Not every log needs immediate analysis. Modern pipelines now allow teams to route high-signal logs, like authentication failures or denied firewall requests, directly to SIEM tools for real-time analysis. Lower-signal data, such as successful logins or benign file accesses, can be sent directly to a central data lake.

The advantage is cost control without loss of coverage. When investigations require it, teams can retrieve dormant logs selectively, analyzing only the relevant portions.

In 2025, 58% of organizations report shifting non-critical data to cold storage to optimize real-time detection capacity. Selective retrieval operationalizes that shift without losing forensic traceability.

2. Improve Forensic Readiness While Reducing Always-On Costs

Maintaining hot access to all historical data is financially impractical. Enterprises using selective retrieval can store 12 to 24 months of logs affordably in cold storage and retrieve subsets for investigations as needed.

One European engineering firm reported a 45% reduction in SIEM licensing fees after adopting selective retrieval, while simultaneously extending their log retention period from six months to two years.

This approach separates storage from processing, giving security teams access to necessary data without ongoing analysis overhead.

3. Balance Security Priorities with Compliance Mandates

Compliance teams often require long-term data retention, but this should not dictate analytics workflows. By tagging data on ingest, teams can store all logs for audit readiness while restricting active analytics to data supporting detection priorities.

In 2025, 69% of financial services organizations reported using metadata tagging to manage regulatory and operational log requirements separately. This ensures compliance reporting needs are met without compromising security team efficiency.

4. Retain Full Visibility Across Noisy Data Sources

Firewall logs are a prime example of high-volume, low-actionability data. Many teams historically chose between retaining denied requests or successful connections due to storage and processing constraints.

Selective retrieval removes that tradeoff. Both denied and accepted traffic logs can be stored without analysis, preserving full visibility. When a post-incident review demands it, analysts can retrieve only the relevant data window to answer specific questions.

In regulated sectors like healthcare and manufacturing, 64% of security teams now cite selective retrieval as essential for supporting internal investigations without expanding real-time infrastructure.

5. Treat the Data Lake as an Operational Asset

Data lakes are no longer passive archives. Modern architectures support preview-before-ingest capabilities and conditional retrieval triggers, transforming data lakes into active security resources.

Instead of analyzing everything or ignoring large datasets, teams can treat stored logs as a reservoir to be accessed precisely when needed — whether for compliance audits, insider threat detection, or incident response.

The result is not just cost savings. It is operational flexibility. In 2025, 71% of CISOs surveyed by TechTarget acknowledged that selective retrieval had directly improved their team’s investigative efficiency.

Looking Ahead

Selective retrieval represents a practical shift in how CISOs manage data growth, security visibility, and compliance obligations. By separating storage from analysis, security leaders can cover more risk scenarios without overextending budgets or infrastructure.

As data volumes continue rising, adopting selective retrieval is becoming less of a niche strategy and more of an operational standard.

Graylog supports these strategies with flexible ingestion, metadata tagging, and retrieval pipelines, enabling CISOs to protect, retain, and investigate without adding unnecessary drag to daily detection operations.

Ready to stop paying for data you’re not actively using? Learn how Graylog’s selective retrieval unlocks forensic readiness and compliance flexibility—without overwhelming your SIEM or your budget. See how it works.

Email threats aren’t slowing down. From credential phishing to malware-laced attachments, email remains one of the most exploited entry points for attackers. If you’re already using Mimecast to help mitigate that risk, you’re ahead of the curve — but raw log data only gets you so far.

Starting with Graylog 6.2.3, you can pull logs directly from Mimecast using API v2.0 and view them immediately with built-in Illuminate Dashboards. This streamlines investigations, enhances visibility, enables cross-log correlation, and reduces time spent capturing critical information.

Why Integrate Mimecast with Graylog?

Mimecast logs contain a wealth of email security telemetry: blocked threats, quarantined messages, impersonation attempts, URL protections, DLP triggers — you name it. But your analysts are missing the bigger picture unless you’re pulling that data into your central logging and detection platform.

By integrating Mimecast with Graylog:

• You centralize email security insights alongside endpoint, firewall, and identity logs.
• You reduce pivoting between tools and improve incident response speed.
• You leverage ready-made dashboards and content to cut through the noise.

Prerequisites

Mimecast Setup

Before getting started, make sure the following prerequisites are covered:

• A valid Mimecast account
• A configured Mimecast API application (see Mimecast documentation for setup steps)
• API user with appropriate admin permissions based on log types

Graylog Input Configuration

To configure the Mimecast input in Graylog:

1. Go to Graylog > Inputs

2. Select the Mimecast input and click Launch new input

You’ll be prompted to configure the following:

• • • Input Name
      A user-defined name (e.g., “Mimecast Email Logs”)
    • Client ID
      From your Mimecast API application
    • Client Secret
      Also from your API application
    • Log Types to Collect
      Select the types of logs you want to ingest (default: all). At least one is required.
    • Polling Interval
      How frequently Graylog polls Mimecast (minimum: every 5 minutes)
    • Enable Throttling
      When enabled, Graylog will pause new message intake from this input if the system is behind in processing

3. Enable the Graylog Illuminate Mimecast Processing Pack and Spotlight

That’s it — once saved, the input begins pulling in data and Illuminate goes to work.

Illuminate Technology Pack

The content pack supports the following log types. Generic processing will be provided for log types not listed.

Illuminate Dashboards: Instant Insights from Day One

No need to build dashboards from scratch. With the Mimecast integration, Illuminate provides prebuilt dashboards that offer:

Email Threat Overview

See overall message volume, threat counts, and detection trends across time.

Saved Search

Quickly save searches for sharing to the team or creating an investigation using email parameters.

How This Helps Analysts

It’s not just about pretty charts. Integrating Mimecast with Graylog improves the analyst experience in several key ways:

• Centralized Investigation
  Email events are side-by-side with endpoint, DNS, firewall, and user activity logs
• Less Manual Correlation
  No need to bounce between tools to get a full picture of an email incident
• Faster Detection and Response
  Dashboards highlight high-risk activity, helping analysts focus on what matters
• Operational Context
  Graylog’s enrichment and detection rules help connect Mimecast data to broader attack patterns

Ready to Try It?

If you’re already running Graylog Enterprise 6.2.3 or later, setting up Mimecast integration takes just a few minutes. With prebuilt dashboards and structured log inputs, you’ll go from raw data to actionable insights fast and finally get the email threat visibility your team needs.

Over the last few years, news reports around ransomware attacks have noted that the attacks are increasingly sophisticated. Simultaneously, they say that the attackers are less sophisticated than in the past. While these two statements appear to conflict with each other, they are both true when viewed through the lens of the current cybercriminals business models.

Ransomware-as-a-Service (RaaS) applies a subscription payment model to cybercriminal ransomware activities. The ransomware developers focus on evolving increasingly sophisticated attacks then sell these capabilities to less sophisticated cybercriminals. This ecosystem makes it easier for less technical criminals to deploy attacks while enabling the creators to make the ransomware more difficult to defend against.

With insight into how Ransomware-as-a-Service works, security teams can implement additional controls to mitigate risk.

What is Ransomware-as-a-Service (RaaS)?

Ransomware-as-a-Service (RaaS) is a cybercrime business model selling ransomware tools based on the legitimate Software-as-a-Service (SaaS) subscription model. With the RaaS model, developers build the malware then sell it to affiliates who carry out the attack. This process enables less-skilled cybercriminals to deploy sophisticated ransomware attacks.

With the RaaS model, cybercriminals can expand their reach while making prevention and detection more difficult for security teams.

How does the RaaS model work?

With the RaaS model, threat actors operationalize ransomware attacks and provide cybercriminals with the same services that a legitimate SaaS product company would offer, including customer support services and a payment portal.

At a high level, the RaaS model consists of three types of adversaries:

• Operators: Create and sell the malware, campaign infrastructure, and services
• Initial access brokers (IABs): compromise networks and then sell the unauthorized access to other cybercriminals
• Affiliates: purchase and deploy the ransomware

While the specifics are unique to each operation, the overall structures tend to fall into a few models.

Monthly subscription

In this model, affiliates pay a recurring fee for continued access to the latest ransomware tools and services. The affiliates avoid the upfront costs and technical knowledge necessary for creating the ransomware from scratch. The operators gain recurring revenue from the affiliates while remaining distanced from the actual attack, enabling them to evade law enforcement.

One-time fee

Under this model, the affiliates pay the cybercriminal version of a lifetime license for full access to the ransomware code. The affiliate retains access to the tools, enabling them to run ransomware operations without further financial obligations. For affiliates who want to manage multiple attacks over a long period of time, this might be a cost-effective option.

Affiliate programs

An affiliate program uses a profit sharing model where the affiliates and operators split the ransom as payment. While payment structures differ across ransomware groups, they often fall under three structures:

• 70% to affiliate, 30% to operators
• 80% to affiliate, 20% to operators, seen recently with LockBit
• 90% to affiliate, 10% to operators, seen recently with Ransom Hub or APT 73

These arrangements are often flexible, with an affiliate’s skill sets impacting commission. Affiliates who have teams, infrastructure, and tools often receive a higher percentage of the ransom than less sophisticated cybercriminals.

What are the different extortion categories?

In the early days of ransomware, attackers would encrypt an organization’s data, providing the decryption key only once the victim paid the ransom. In response, organizations implemented more sophisticated backup and restoration capabilities for improved business resilience.

Recently, cybercriminals have changed their methodologies. Today, ransomware includes data theft, holding the sensitive information hostage until victims pay the ransom. These extortion methods include:

• Single extortion: stealing data then asking for money
• Double extortion: publishing some sensitive data and threatening to put it on the dark web
• Triple extortion: pressuring companies into paying ransom through other means, like exposing file listings or sending victims emails

What are real-life examples of RaaS groups?

Although the RaaS ecosystem has seen some changes recently due to law enforcement actions, some groups are well-known across the landscape.

DarkSide

Linked to the 2021 Colonial Pipeline attack, DarkSide is known for targeting large corporations and using double extortion tactics. In June 2021, law enforcement seized cryptocurrency valued at $2.3 million, representing the proceeds of this attack.

LockBit

First appearing in 2019, this group is commonly considered the most prolific ransomware group, linked to 2,000 victims and stealing more than $100 million. Its malware, LockBit 3.0 (LockBit Black), added double extortion tactics. In 2024, law enforcement seized control of the group’s infrastructure and its alleged administrators, securing convictions of several affiliates.

REvil

Also called Sodinokibi, this group was involved in several high-profile attacks, like ones against JBS Foods and Kaseya. In May 2024, one group member was sentenced to over thirteen years in prison for his role in attacks related to over $700 million in ransom payment.

Conti

Linked to attacks against over 900 global victims, this group notably attacked Ireland’s Health Service Executive (HSE), severely disrupting healthcare services. In 2023, law enforcement charged four Russian cybercriminals over their involvement with the group.

Best Practices for Mitigating Ransomware Risks

The RaaS model increases the volume of ransomware sophisticated attacks by lowering the barrier to entry. With these best practices, you can improve your security and reduce risk.

Improve credential hygiene

With IABs selling initial access, improving credential hygiene is a fundamental security control. Implementing multi-factor authentication (MFA) enables you to mitigate risks by providing challenge questions related to something people have (like a smartphone) or something people have (like a face ID).

Monitor for credential exposure

Monitoring data breach information can help you identify leaked credentials related to your employees. Often, people reuse the same password across personal and professional logins, so identifying employee credentials leaked in previous data breaches can improve your security.

Reduce the attack surface

Every network access point is a location where attackers can gain initial access. Some typical ways to reduce the attack surface include:

• Limiting access according to the principle of least privilege
• Reviewing firewall rulesets for outdated rules with excess permissions
• Disabling unnecessary device and software functionalities
• Blocking known malicious IP addresses

Regularly scan for vulnerabilities and apply security updates

IABs often target vulnerabilities as a way to gain initial system and network access. Scanning for vulnerabilities across software, hardware, and firmware on network-connected devices closes this security gap when combined with installing security patches as quickly as possible.

Incorporate threat intelligence

Threat intelligence provides real-time insight into operator, IAB, and affiliate attack methodologies. For example, threat intelligence can provide insight into the known vulnerabilities that these groups target, helping to prioritize vulnerability remediation actions.

Graylog Security: Contextual Risk Insights for Improved Security Operations

Graylog Security’s contextual risk scoring, powered by Adversary Campaign Intelligence, incorporates threat intelligence into our risk scoring to amplify real threats and reduce noise. With Graylog, security teams can prioritize activities based on asset criticality and connect the dots between alerts to reduce alert fatigue.

Graylog Security’s Illuminate bundles map Sigma rule detections to the MITRE ATT&CK framework so you can gain immediate value from your logs and improve your security alert capabilities.

To see how Graylog Security gives you the SIEM that never asks you to compromise, contact us today.

On a sunny summer vacation day, your childhood self is running around a playground looking everywhere for a small piece of paper as part of a treasure hunt. Each clue you find leads to another, then another, until you finally locate the hidden treasure. Investigating a security incident is similar to this process, but instead of clues written on paper, your clues are digital artifacts that attackers left in your systems.

These digital artifacts are called indicators of compromise (IoCs). Like every good mystery novel reminds you, every criminal makes a mistake, leaving behind clue. IoCs can be anything from unusual login to unauthorized file changes, the tiny changes to your complex systems that they hope will go unnoticed.

For security teams, knowing the most common indicators of compromise can improve key threat detection and response (TDIR) metrics, like mean time to investigate (MTTI) and mean time to contain (MTTC).

What are indicators of compromise (IOCs)?

Indicators of Compromise (IoCs) are the clues that threat actors leave behind after gaining unauthorized access to systems, networks, and devices. Security teams can search their environments for these clues to confirm a security incident or data breach. By monitoring IoCs in real-time, security teams proactively mitigate risk.

IoCs fall into the following four categories:

• Network-based: unusual traffic patterns that indicate potential phishing, malware, unauthorized access, or other sophisticated attacks with symptoms like suspicious IP address or malicious domain names
• Host-based: activities on individual systems or endpoints, like unexpected changes in system settings, processes, or permissions
• Email-based: signs of phishing or malware in suspicious emails, including malicious attachments, strange email addresses, spoofed sender information, spikes in spam, odd messages from known contacts, or unusual email patterns
• Behavioral: suspicious user behavior that can indicate an account takeover, like odd login actions or unusual network traffic.
• Third-party: threat intelligence that provides insight into new and evolving threats, often providing ana application programming interface (API) so security teams can incorporate the data into their security information and event management (SIEM) solution

17 Common Indicators of Compromise

By detecting unusual system behavior as quickly as possible, you can reduce an incident’s severity and potential impact. By looking for these common IoCs, you can take a more proactive approach to security.

1.   Network traffic anomalies

Network traffic anomalies can indicate potential data theft or connection to a threat actor’s command and control (C2) infrastructure. For example, a sudden spike in data transfers can indicate attackers exfiltrating sensitive information.

2.   Unusual sign-in attempts

As part of monitoring user access, you should look for unusual sign-in attempts that can indicate an account takeover attack or credential stuffing attack. Some examples of this behavior include login attempts from unexpected geographic locations or multiple failed logins in a short timeframe.

3.   Geographical anomalies

Most organizations know where their employees work or know their travel patterns. Any geographical anomaly, like user access or server communications, can indicate a potential incident. Additionally, some geographic regions are known to be a haven for cybercriminals, so you may want to focus monitoring for those areas.

4.   Privilege account irregularities

Privileged accounts, both human and machine, have more access to sensitive data, resources, and assets than standard accounts. Attackers target these accounts so they can gain unauthorized access to sensitive information or move laterally across networks.

5.   Changes to systems configurations

To weaken defenses or evade detection, attackers often make unapproved changes to system configurations. For example, these new changes may indicate that malware introduced a backdoor so attackers can maintain their presence in systems and achieve objectives.

6.   Unexpected software installations or updates

Typically, IT departments define the approved software that users can install. When people install unauthorized software, they may be adding malicious applications to devices. When users are unaware of unauthorized downloads, it might be a malware infection that attackers can use to gain unauthorized access or to deploy additional malware, like ransomware.

7.   Numerous requests for the same file

As organizations moved to the cloud, they implemented access controls around resource and file access. Multiple requests for access to the same file can indicate that attackers are attempting to gain initial access or are using unauthorized access to explore networks and systems.

8.   Unusual Domain Name Systems (DNS) requests

Unusual and high volumes of DNS queries can indicate a malware infection and attackers trying to download data, especially when the requests come from unexpected geographic locations. These indicators are most common when attackers install malware on a server and create a connection to their C2 infrastructure.

9.   Swells in database read volume

Increased database read volume can indicate that attackers are exploring your systems to find sensitive data. Before attackers steal sensitive information, they have to explore databases to find it. When attackers attempt to steal this information, their activities will generate a higher read volume than normal.

10.   HTML response sizes

Web applications often have larger HTML response sizes when attackers are trying to deploy an attack against them. For example, in a SQL injection attack, the database connected to the application will try to send more data than usual, increasing the HTML response size.

11.   Mismatched port-application traffic

Applications typically define the accepted ports for transmitting data. For example, ports 0 though 1023 are often used by common, widely used services, like system processes, operating systems, and default applications. If an application is using an usual port, an attacker may be trying to evade detection.

12.   Suspicious registry or system file changes

After gaining an initial foothold, attackers often make changes to registries and system files to establish and maintain persistence. For example, attackers often install additional malware and tools once they have unauthorized system access.

13.   Influx of spam emails

A sudden increase in spam emails can be related to an attack in two different ways. Attackers may compromise an email account and use it to send emails to other employees. Additionally, spam emails are often part of phishing attacks, so a sudden influx of these messages may indicate that attackers are targeting the organization.

14.   Moved or aggregated data

When attackers are preparing to exfiltrate data, they often try to create a collection point to evade detection. With data transferring quickly from one or two locations, security teams may not detect the issues until the attackers complete the process. For example, attackers may try to move files to a recycle bin’s root folders where no one would think to look.

15.   Non-human website traffic

Threat actors often use bots to deploy attacks, like brute force or Distributed Denial of Service (DDoS) attacks. Some indicators of non-human website traffic include:

• Abnormally high pageviews and bounce rates
• Anomalous session durations
• Traffic spikes from unexpected locations

16.   Changes to mobile devices

Attackers increasingly target mobile devices because employees often use them for work. For example, a smartphone that starts running slowly might have a mobile malware on it. If your organization provides and manages mobile devices, looking for configuration changes and new profiles can help identify a potential attack.

17.   System outages or reduced performance

When attackers deploy a DDoS attack, they send high volumes of requests to servers. Clogged with so many requests, the servers are unable to respond, disrupting services. In some cases, threat actors use a DDoS attack to distract security teams so they won’t detect a different attack, like a ransomware deployment.

Graylog Security: Cut Through the Noise with Contextual Risk Scoring

While IoCs provide valuable insight into activities happening across your environment, they often lack context which can lead to false positives. For example, an offline network device could be causing network latency or a system outage, not a DDoS attack. Without context, security teams find themselves investigating alerts that may be unrelated to a security incident or data breach.

Graylog Security’s contextual risk scoring, powered by Detection Chains, amplifies real threat and suppresses the rest. By leveraging threat intelligence and our risk scoring, you can prioritize responded based on asset criticality and connect the dots between alerts to reduce alert fatigue.

To see how Graylog Security gives you the SIEM that never asks you to compromise, contact us today.

Security fatigue gets attention for a reason. Phishing emails, authentication prompts, and constant vigilance all take a toll. But alert fatigue is the deeper, more destructive force. It overwhelms analysts, delays response, and creates blind spots that adversaries exploit.

Security teams today are buried under noisy alerts and fragmented tooling. False positives waste time. Manual triage eats up valuable analyst hours. Eventually, burnout sets in and threats slip by. It is not a hypothetical risk. Some of the most significant breaches in recent years have been traced back to missed warning signs that were buried in overwhelming alert noise.

This is not just a technology problem. It is a process problem shaped by outdated systems.

Why Alert Fatigue Persists

Most security teams still depend on traditional SIEMs. These systems rely on static rules and high-volume alerting. That worked when data volumes were small and threats were simple. Today, it fails.

Teams now process more log data than ever, but legacy tools cannot keep pace. Searching across large datasets becomes painfully slow. Storage costs escalate. Licensing models force trade-offs between visibility and budget. Many organizations are forced to drop logs just to stay within limits.

At the same time, attackers are more subtle. They stretch campaigns over weeks. They blend in. They do not set off single, high-fidelity alarms. They leave a trail of weak signals that are only meaningful when seen together.

According to the 2025 Verizon Data Breach Investigations Report, alert overload contributed to delayed detection in more than half of all breaches. When threat signals get buried in noise, organizations don’t just lose time—they lose ground.

Campaign-centric Detection is the Shift That Matters

Instead of relying on single alerts, Graylog helps teams link related activity into threat campaigns. This approach cuts through noise and focuses analyst attention on actual adversary behavior.

Campaign-centric detection connects isolated events to uncover a full attack narrative. That means fewer alerts, but each one is more meaningful. Analysts spend less time chasing dead ends and more time stopping real threats.

This matters now more than ever. A 2025 SANS SOC survey found that alert triage consumes more time than any other task in the detection and response cycle. Fifty-eight percent of teams named it their biggest drain, far surpassing investigation and response. Analysts need better signal quality, not more noise.

The impact of campaign detection is immediate:

• Stronger signals with less clutter
• Threat visibility aligned with business context
• Faster, more confident decisions in the moment

Recent campaigns like Volt Typhoon and Midnight Blizzard show how attackers rely on quiet, persistent techniques. Campaign correlation helps those techniques stand out.

Traditional SIEMs Cannot Keep Up

Legacy SIEMs were not built for behavior-based detection. They count events, not context. They generate alerts, not answers.

A campaign-centric model does more than log what happened. It helps analysts understand why it happened and how it fits into a broader adversary strategy. That context changes the way security teams work, and the way they communicate with the business.

Buyer expectations are shifting fast. According to Gartner, security teams are no longer satisfied with SIEMs that overwhelm users with disconnected alerts and rigid rule logic. Instead, there is growing demand for tools that support campaign-based detection and are built with the analyst experience in mind. This reflects real operational pain—burnout, alert fatigue, and the cost of slow investigations—not just a wish list for better features.

This change also benefits leadership. When analysts can frame threats as connected campaigns rather than isolated events, they offer clearer insights into what happened, why it matters, and how to respond. That makes security risks easier to explain, and easier to defend at the executive and board level.

Better Outcomes for the Entire Team

The move to campaign-centric detection brings measurable benefits:

• Less burnout across Security Operations teams
• Smarter logging decisions without budget surprises
• Clearer threat narratives for executive stakeholders

This shift is not about tuning rules. It is about enabling people to do their best work. By giving analysts better context and fewer distractions, campaign thinking delivers more efficient operations, faster response, and higher confidence.

Campaign-based detection is working. And for teams that want to stop reacting to individual alerts and start understanding adversary behavior, this is the clearest path forward.

Cut through alert fatigue. See how Graylog Security helps analysts detect real threats, not just noise.

Free Online Graylog Analyst Training

Efficient log management and analysis are crucial for maintaining robust IT infrastructures. To empower IT professionals and enthusiasts with the skills needed to harness the power of log data. Sign up at the Graylog Academy and take our Free Online Graylog Analyst Training! 

Why Graylog?

Graylog is a leading open-source log management tool that simplifies the process of collecting, indexing, and analyzing log data. With its powerful features and user-friendly interface, Graylog enables organizations to gain valuable insights, enhance security, and improve operational efficiency. 

What You’ll Learn at Graylog Academy

Our comprehensive on demand Graylog Analyst training program covers a wide range of topics, ensuring participants gain a deep understanding of the platform and its capabilities. Designed from the ground up by internal Grayloggers and experts, anyone can sign up for Graylog Academy Training. Did we say pass each test and you get your Graylog certificate? Yes!

Here’s some of what you can expect:

Search Fundamentals: Find out how easy it is to search your logs in Graylog
Introduction to Graylog Dashboards: Learn about the architecture and core components of Graylog.
Log Ingestion: Techniques for collecting and parsing log data from various sources.
Pipelines, Parsing and Graylog Information Model: How Pipelines work with efficiency
Dashboards and Visualization: Create custom dashboards and visualizations to monitor key metrics.
Events, Alerts and Notifications: Set up alerts and generate reports to stay informed about critical events.
Intro to API Security: A course highlighting the benefits of utilizing the API Security product.
Interactive Tours: Data Lake, Sigma Rules, Input Setup, Security Events

Who Should Attend Graylog Academy?

This training is ideal for:

• IT professionals looking to enhance their log management skills with Graylog
• Security analysts who aim to improve threat detection and response
• System administrators seeking to optimize their IT infrastructure
• Anyone interested in learning about log management and analysis

How to Enroll

Enrollment is simple and free! Go to Graylog under “Learn” and select “Academy” or visit our training page here to sign up. The course is self-paced, allowing you to learn at your own convenience. Check out the additional subscription in class courses as well!

Graylog Security Notice – Escalated Privilege Vulnerability

Date: 24 June 2025
Severity: High
CVE ID: submitted, publication pending
Product/Component Affected: All Graylog Editions – Open, Enterprise and Security

Summary

We have identified a security vulnerability in Graylog that could allow a local or authenticated user to escalate privileges beyond what is assigned. This issue has been assigned a severity rating of High. If successfully exploited, an attacker could gain elevated access and perform unauthorized actions within the affected environment.

Affected Versions

Graylog Versions 6.2.0, 6.2.1, 6.2.2 and 6.2.3

Impact

Graylog users can gain elevated privileges by creating and using API tokens for the local Administrator or any other user for whom the malicious actor knows the ID.

For the vulnerability to be exploited, an attacker would require a user account in Graylog. Once authenticated, the malicious actor can proceed to issue hand-crafted requests to the Graylog REST API and exploit a weak permission check for token creation.

Update June 30th, 2025: Please see CVE-2025-53106 for details

Workaround

In Graylog version 6.2.0 and above, regular users can be restricted from creating API tokens. The respective configuration can be found in System > Configuration > Users > “Allow users to create personal access tokens”. This option should be Disabled, so that only administrators are allowed to create tokens.

Full Resolution

A fix has been released in Graylog Version 6.2.4. We strongly advise all affected users to apply the patch as soon as possible.

6.2.4 Download Link

6.2.4 Changelog

Recommended Actions

Check Audit Log (Graylog Enterprise, Graylog Security only)

Graylog Enterprise and Graylog Security provide an audit log that can be used to review which API tokens were created when the system was vulnerable. Please search the Audit Log for action: create token and match the Actor with the user for whom the token was created. In most cases this should be the same user, but there might be legitimate reasons for users to be allowed to create tokens for other users. If in doubt, please review the user’s actual permissions.

Review API token creation requests

Graylog Open does not provide audit logging, but many setups contain infrastructure components, like reverse proxies, in front of the Graylog REST API. These components often provide HTTP access logs. Please check the access logs to detect malicious token creations by reviewing all API token requests to the /api/users/{user_id}/tokens/{token_name) endpoint ( {user_id) and {token_name) may be arbitrary strings).

Graylog Cloud Customers

Please note: All Graylog Cloud environments have already been updated to version 6.2.4 and have also been successfully audited for any attempt to exploit this privilege escalation vulnerability.