We’re all exhausted—both by the problem and by hearing about it. False positives and overwhelming alert volume have long plagued security operations. And despite years of innovation, solutions have remained elusive.

Alert volume. Alert fatigue. SOC burnout.

This persistent problem puts security teams in a tough position:

• Enable a broad set of detections to catch possible threats—knowing it will lead to high alert volume, false positives, and potential SOC burnout.
• Or, tune alerts tightly or disable noisy ones—risking blind spots and missing critical early indicators of an attack.

For CISOs and SOC managers, it’s a lose-lose scenario. And worse, the challenge is always shifting as the attack surface expands, adversaries evolve, and detection techniques multiply.

Adding more security tools and analytics often makes it worse, layering on even more data for analysts to triage.

The Real Answer: Evidence, Not Just Alerts

The solution isn’t finding the mythical “perfect alert” that only fires on true positives. It’s about automating the discovery of corroborating evidence that proves (or disproves) whether an alert points to a real threat.

If multiple pieces of evidence support the alert—its legitimacy is strengthened.

If no supporting data is found—it’s likely a false positive.

This is where Graylog 6.2 comes in.

Introducing A Smarter Way to Assess Risk

With version 6.2, Graylog enhances its Asset Risk Model, bringing greater precision to how risk of compromise is calculated—so you can focus on what matters most.

Recap: What Is Graylog’s Asset Risk Model?

Graylog Assets are an identity-construct for users and systems, recognizing that different log sources may reference the same “user” or “system” differently. The Asset Risk model was introduced last November, shifting triage from alert-based to asset-based. Instead of evaluating every alert in isolation, you focus on high-risk assets—users or machines—based on their composite risk score.

Each alert contributes to that score by factoring in:

• Severity of the detection method (e.g., correlation, outliers, ML anomalies)
• Environmental context
• Frequency and diversity of alerts

What’s New in 6.2?

Graylog 6.2 adds Adversary-Informed Defense to the model—introducing threat campaign awareness:

• Alerts are enriched with knowledge of adversary campaigns.
• Alerts linked to known threat campaigns are assigned higher risk.
• As more alerts from the same campaign surface—risk increases exponentially.

This creates an orthogonal signal, linking related evidence across both assets and threat campaigns, delivering a higher fidelity risk score.

Why This Matters

Collapsing individual alerts into asset-centric risk scores delivers immediate operational benefits:

✅ Less Time on False Positives

When a single alert fires but no corroborating activity is found, the asset risk remains low—reducing time spent chasing noise.

✅ No More “Sophie’s Choice”

The burden of tuning every rule to perfection is reduced. Graylog automatically groups related findings—even across assets—making alert triage more manageable and reducing the risk of blind spots.

✅ Faster Investigations

The initial triage questions—“who, what, where”—are answered automatically by the asset context and associated evidence, letting analysts jump straight into deeper investigation.

The New SOC Efficiency Model

The triad of:

• Asset Risk
• Exposure Awareness
• Adversary-Informed Defense

delivers the precision, automation, and prioritization that modern security operations demand.

When paired with Graylog’s embedded investigation guidance and automation, the result is a leap forward—whether you’re just starting your security journey or running a mature SOC.

What does it really mean to have a SIEM Without Compromise? 

For too long, security teams have been stuck in a no-win game—forced to choose between visibility and cost, detection breadth and team capacity, automation, and control. Every decision felt like a trade-off, with real-world consequences: dropped logs, missed alerts, and inconsistent response when it mattered most. 

With the Spring ’25 release of Graylog Security 6.2, we’re eliminating those compromises. Our latest innovations empower you to log everything, detect what matters, and respond with precision—without overloading your team or your budget. 

Let’s break down the three most common SIEM trade-offs and how Graylog 6.2 puts them to rest. 

Log Collection: No More “All or Nothing” 

The Trade-Off: 

Most SIEMs license based on volume, source, or compute, making log collection a budgetary balancing act. You either drop logs to control costs or accept unpredictable licensing spikes. Once dropped, those logs—and their forensic value—are gone forever. 

The Graylog 6.2 Solution: 

With Graylog’s native pipeline management, including Data Routing and Graylog’s provided Data Lake, you don’t have to choose. Route only high-value logs (used for active dashboards, detection, and analytics) into licensed hot storage. Send everything else into your standby data lake, where it is searchable, restorable, and completely license-free. Graylog lets you Preview data in your data lake prior to retrieval, and provides selective retrieval options, ensuring the data in your SIEM is the data driving decisions.  

You get full retention with cost control—perfect for compliance, audits, and threat hunting. Your storage, your rules—on-prem or in the cloud. 

Threat Detection: From Alert Overload to Risk-Led Action 

The Trade-Off: 

More detections = more alerts = more noise. To keep alert fatigue in check, teams are forced to disable or under-tune detections—limiting early visibility into attacker behaviors. As threat campaigns evolve, keeping detection content current without overwhelming the SOC becomes impossible. 

The Graylog 6.2 Solution: 

Enter Graylog’s Adversary Informed Defense. Rather than triage individual alerts, 6.2 automatically recognizes adversary groups Tactics, Techniques, and Procedures (TTPs), chaining detections together and exponentially increasing risk scoring with each additional corroborating detection. Going a step beyond tagging detections based on their MITRE ATT&CK tactic and technique, Adversary Informed Defense uses real-world threat campaign details to recognize the presence of an attack in your environment, even if individual activities are spread over days, weeks, even months.  

And this inherently works with Graylog’s Asset Risk model, allowing teams to confidently enable more detections without drowning in alert noise, keeping them ahead of attacker TTPs without burning out their analysts. 

Incident Response: Ditch the Binder, Evolve Beyond the Playbook 

The Trade-Off: 

SOAR was supposed to solve alert triage with automation. In reality, most playbooks are rigid, brittle, and require expert knowledge to build and maintain. Meanwhile, LLM-based copilots introduce inconsistency—same question, different answer. 

The Graylog 6.2 Solution: 

We deliver the best of both worlds: 

• Structured guidance with every event via embedded procedural steps 

• Context-aware AI assistance via LLMs that analyze investigation evidence in real time 

This ensures consistent, repeatable investigations with dynamic, context-enriched support—no more toggling between static flows and unpredictable copilots. 

Why This Matters 

With Graylog Security 6.2, security teams no longer need to compromise: 

Get Started: Experience SIEM Without Compromise 

Graylog’s Spring ‘25 release isn’t just a feature drop—it’s a shift in how modern security teams operate, adapting to your environment, in support of lean teams, and keeps you ahead of adversaries, not buried under alerts. 

HOUSTON — April 28, 2025 — Graylog, the no-nonsense platform for Security, API protection, and IT Operations, today launched its Spring 2025 release of Graylog Security—pushing further past the limits of traditional SIEM. Building on the Fall 2024 release (version 6.1), Graylog sharpens analyst workflows, accelerates time-to-value, and sets a new bar for speed and flexibility in threat detection.

With Adversary Campaign Intelligence, Data Lake Preview, Selective Data Restore, and Threat Coverage Analyzer, Graylog can now equip teams with better detection, real-time context, and more control over what matters. Analysts get alignment between content and the data it’s meant to catch, while CISOs get the visibility to prove it’s working without making tradeoffs. 

“SIEMs have forced teams into a corner for too long—more logs mean more cost, more alerts mean more noise, and every pivot adds drag,” said Seth Goldhammer, Vice President of Product Management at Graylog. “This release flips that model. We’re using automation to clear the clutter, dial in detection, and make sure your stored data delivers value—not just volume.”

Adversary Campaign Intelligence

Graylog’s Adversary Campaign Intelligence redefines threat detection by continuously assessing activities based on their common targets, asset value, and exposure levels, and identifying their relationship with known attack campaigns. This calculated true attack probability reduces noise and surfaces at-risk users, endpoints, and entities by automatically corroborating evidence and context.

With updated detections to support Sigma 2.0 and responses empowered with AI guidance and automation, analysts act faster, triaging only what’s relevant and cutting down response time.

Data Lake Preview

Graylog allows for direct alignment to SIEM costs and the data that answers questions without sacrificing visibility by extending the data routing and data lake capabilities launched in the Fall 2024 release. Graylog’s Data Lake Preview allows teams to see if the data they need is in the Graylog Data Lake before retrieving a data set. Then, with Selective Data Retrieval, teams retrieve a narrow range of log messages on demand, greatly reducing their license consumption. 

Threat Coverage Analyzer

Graylog’s Threat Coverage Analyzer gives security leaders clarity into what their teams are detecting—and what they might be missing. This feature highlights detection gaps mapped to the MITRE ATT&CK framework, guiding users to detect content aligned to their SIEM’s log collection and new log collection strategies to strengthen coverage posture through data-driven decisions.

Graylog Live at RSAC 2025

The Graylog Spring 2025 release is now live. Visit Graylog.com to explore new features and learn more, or join us at #RSAC 2025, Booth S-3134, to see a live demo.

HOUSTON and HONG KONG –  April 15, 2025 – Graylog, a leader in Threat Detection, Investigation, and Response, is deepening its commitment to the APAC region following a 6.5X increase in sales over the past two years — the fastest growth rate of any market for the company. As demand for modern security and log management solutions continues to rise, Graylog is expanding its footprint with a new office in Singapore, complementing its existing presence in Hong Kong. To further support this growth, Graylog has partnered with RIPEN, a leading IT security consultancy, to deliver dedicated Tier 1 and Tier 2 customer support across the region.

“Our growth in APAC isn’t just about numbers—it’s about ensuring our customers can quickly detect and respond to security threats,” said Adam Abernethy, Vice President of Customer Enablement at Graylog. “With RIPEN’s deep expertise and hands-on experience using Graylog in real-world security operations, customers get direct access to skilled professionals who can help them solve problems fast.

Expanding Graylog’s Global Sales and Support Network

Following the establishment of the company’s regional APAC office in 2022, Graylog is further expanding with the opening of an office in Singapore and the appointment of Gerald Lum as Regional Vice President of Sales. In this role, Mr. Lum will oversee the sales operations and performance in APAC, drive revenue targets, and implement sales strategies.

“As a cyber security evangelist with more than 20 years of sales and leadership experience, we welcome Gerald to the team and look forward to his contributions as we continue to help organizations across the APAC region enhance security operations, improve log management efficiency, and reduce operational costs,” said Joshua Ziel, Chief Sales Officer at Graylog.

The region continues to play an increasingly vital role in the company’s global expansion. As adoption accelerates, Mr. Lum’s arrival and the RIPEN partnership ensures that security teams have the resources, expertise, and support they need to maximize the value of their Graylog deployments.

Localised Support for APAC Security and IT Teams

RIPEN’s team will handle in-region support for Graylog’s Threat Detection, Investigation, and Response (TDIR) and Centralized Log Management solutions, helping customers:

• Resolve security issues faster with direct access to experienced professionals
• Get support in local languages for Tier 1 and Tier 2 troubleshooting
• Streamline security operations by optimizing log management and threat detection workflows

“Having witnessed the transformative power of Graylog first-hand, we are thrilled to join forces to empower security and IT teams across APAC,” Stated Raymond CHENG, VP of Operation at RIPEN. ” Our collaboration will provide APAC customers with an unmatched advantage – the combined strength of our specialized knowledge and Graylog’s powerful technology – enabling them to detect threats faster, respond more effectively, and ultimately, stay ahead of the evolving threat landscape.”

RIPEN’s credentials include:

• Accreditation from the Hong Kong Government’s Government IT Products (GITP) Scheme
• ISO 9001:2015 certification from Accredited Certification International Limited (ACi)
• AWS Cloud Practitioner and AWS Solutions Architect Associate certifications

APAC regional support is available Monday through Friday, 9:00 to 18:00 HKT, complementing Graylog’s existing global support coverage.

In cybersecurity, the adage “what’s old is new” continues to hold true as attackers resurface longstanding techniques or repurpose them with new twists and adaptations. The popularization of Living Off the Land Binaries (LOLBins) — legitimate, Windows-native tools commonly abused for malicious uses — is a great example of this. Many of these methods have existed for decades yet remain effective in the modern security landscape, especially as many organizations are still ill-advised and unequipped to combat them. Being able to spot Mustang Panda’s use of MAVInject in recent campaigns is very important for security teams.

The LOLBin star for today’s blog is Microsoft Application Virtualization Injector (MAVInject) which is (un)surprisingly still kicking since its first buzz around 2017. We’ll cover its particular role in a novel attack chain reported by Trend Micro researchers whereby the threat group Mustang Panda combines legitimate components with malicious payloads to reduce likelihood of detection.

In this blog we’ll emulate the infection chain described in the report and analyze the activity it produces in Graylog. Throughout and at the end of the post, we share threat hunting and detection approaches that you can apply in your own environments.

Attack Overview

The attack likely starts with a spear-phishing email attachment. When executed by the victim, IRSetup.exe is used to drop multiple files to the system. In the case of the Trend Micro report, the files were placed in a newly created C:\ProgramData\session directory.

The report’s execution flow diagram seen below shows how the kill chain progresses from the initial dropper all the way to payload execution, ultimately leading to Command and Control (C2) communication to the attacker-controlled server www[.]militarytc[.]com over port 443.

Key elements

• exe opens a decoy PDF to distract the victim while the malicious payload is deployed in the background.
• The legitimate Electronic Arts (EA) application OriginLegacyCLI.exe is executed to sideload EACore.dll, which contains the actual malicious functionality. The DLL is a modified version of Mustang Panda’s TONESHELL backdoor.
• The malware checks if ESET security software is running on the host by looking for its associated processes ekrn.exe or egui.exe.
• If present, it uses MAVInject to inject itself into the legitimate Windows application waitfor.exe and triggers code that establishes the connection to its C2 server.
• Otherwise, MAVInject is skipped and the code is directly injected into waitfor.

“DLL? Sideloading?? Injection???”, one might be thinking as they read through that. Not to worry, these concepts will be demystified as we emulate the chain ourselves later.

It seems that Mustang Panda might’ve found this use of MAVInject to fly under the radar of ESET software specifically, though that remains unclear – ESET since responded that this technique is not a bypass to its protections.

Persistence

 While researching this attack, we came across a report on Any.Run that exhibits a similar kill chain. It includes a persistence mechanism via registry Run key that wasn’t mentioned in the original report.

This mechanism enables the malware to maintain its foothold on the compromised host. Even if the system is restarted, it will be re-infected once the user logs in.

Emulating the Adversary

Lab setup

To emulate and analyze the attack, we’ve set up a lab environment with Graylog Enterprise 6.1.7 and Illuminate Windows Security Event Logs Content Pack enabled to parse, normalize and enrich the logs. Graylog Security is also included to integrate Sigma rule detections.

A Windows Server 2022 system will serve as our “victim host”. Its configuration sends System, Security, PowerShell/Operational, and Defender event logs via Graylog Sidecar to our Graylog instance. Auditing is explicitly enabled for process execution (command line included), registry changes in commonly abused locations, and file system changes in the ProgramData folder.

We’ve built custom binaries — programs, that is — that closely mimic the malware’s core functionality based on Trend Micro’s analysis, all bundled into a custom IRSetup dropper. To trigger the Mavinject flow, we placed “dummy” programs that mimic ESET running processes. This works because the malware only checks for the process names.

Detonating the mimic malware

Aaaaand, detonate💥!

We see that the mimic dropper wrote files to the ProgramData\session folder and auto-launched the decoy PDF. Waitfor.exe is also running in Task Manager.

It looks like the infection chain of our mimic malware followed through. Let’s hop over to Graylog to get a detailed view of the activity that occurred.

IRSetup dropper

 IRSetup.exe itself isn’t malware — it’s created using a legitimate Windows software installer builder named Setup Factory, in this case abused to drop and execute the malicious files. Attackers favor legitimate tools to blend into environments and make it harder for detection logic to separate malicious from benign activity. It also saves them the trouble of implementing these components themselves.

While we don’t have the actual Setup Factory installer, our mimic dropper does replicate its main function. In the screenshot below we see activity marking the beginning of the infection, sorted by ascending time (read top to bottom):

1. Event ID 4688 (process creation) shows IRSetup.exe being executed
2. This is followed by file system events where the installer writes the PDF, EACore.dll, and OriginLegacyCLI.exe files to C:\ProgramData\session
3. The installer proceeds to execute OriginLegacyCLI.exe

This is where the fun begins (props if you know that reference). Shown below is the rest of the infection chain following OriginLegacyCLI.exe execution. We’ll break down each part and write some threat hunting queries along the way.

EACore DLL sideloading

OriginLegacyCLI.exe gets executed in block 1. We don’t have the visibility from these Windows events to see EACore.dll getting sideloaded as a result (Sysmon would help with that), but we can infer that it happened based on the activity following.

So, what is DLL sideloading? Before that even, what’s a DLL?

A DLL, or Dynamic Link Library, is a shared file used by Windows programs to perform certain functions without having to include all the necessary code within the program itself. Developers load and import ready-made code libraries from DLLs into their applications so they don’t have to reinvent functionality that’s already been written.

DLL sideloading is a technique where a legitimate application unknowingly loads a malicious DLL instead of the intended one, allowing attackers to execute their code while appearing legitimate. It’s similar to DLL hijacking, the difference being that the attacker places the trojanized DLL alongside the target application EXE and directly invokes the application to proxy execute the DLL.

In the Mustang Panda infection chain, the attacker positions the legitimate, signed 3rd-party application OriginLegacyCLI.exe and a tampered EACore.dll in the same directory. When OriginLegacyCLI.exe runs, it follows a search order to look for the DLL it needs by name, in this case “EACore.dll”, and load it.

DLLs in the same folder as the application take priority in the search order hierarchy. OriginLegacyCLI finds that the backdoored EACore.dll matches its search first, and loads it unaware that it’s been swapped. Upon load or import of functionality, the malicious code housed in the DLL gets executed.

This method is highly effective because it exploits trust in legitimate applications and is difficult to identify, helping malware evade security detections. For this reason it’s often a preferred execution method by Red Teams and threat actors alike.

ESET check and RegSvr32

At this point the malicious code in EACore is running under the mask of OriginLegacyCLI, and we move to block 2.

According to the Trend Micro report, the malware checks for ESET running on the system and, if present, “registers EACore.dll using regsvr32.exe to execute the DLLRegisterServer function”, seen in the command line:

“C:\Windows\System32\regsvr32.exe” /s “C:\ProgramData\session\EACore.dll”

Put simply, RegSvr32 is a Windows utility that can be abused to proxy execute malicious code. Instead of EACore invoking its own function, it takes the long way of having RegSvr32 do it. The result is the start of the next infection phase now under the parent process of regsvr32.exe.

Again, we see the use of a built-in Windows utility in an attempt to thwart detections.

DLL injection via MAVInject

Now for what we’ve all been waiting for. If you’re here, you’ve probably weathered the technical hailstorm that was the last few sections, and to that I give a swift salute.

We’re now in block 4, where we see waitfor.exe process creation followed by DLL injection into that process using MAVInject.

So, DLL injection.

In this context, DLL injection is a method of executing malicious code inside of another, often legitimate, running process. It takes a DLL and forces the separate process to load and execute it, enabling malicious activity under the guise of that process.

As we see above, the malware first launches the legitimate Windows program waitfor.exe with the intent to inject into it.

“C:\Windows\SysWOW64\waitfor.exe” “Event19030087251541”

It captures the process ID (PID) 6896 of the newly spawned waitfor.exe to be referenced during injection.

It then runs Mavinject.exe to inject itself, EACore.dll, into waitfor.exe referencing its PID 6896.

“C:\Windows\SysWOW64\mavinject.exe” 6896 /INJECTRUNNING “C:\ProgramData\session\EACore.dll”

Once EACore.dll is injected into waitfor.exe, it establishes a network connection to the C2 server for control over the compromised system.

That’s the gist. If you’re here for the details, it triggers an execution flow to decrypt, allocate and execute shellcode that opens a reverse shell to the C2 and sends information about the victim host. The C2 server communicates with the host using a custom command protocol.

We can hunt for MAVInject DLL injection using the following query in Graylog.

process_command_line:/.* \/INJECTRUNNING .*/

Looking for waitfor.exe spawned under regsvr32.exe is another useful query.

process_name:waitfor.exe AND process_parent_name:regsvr32.exe

Decoy PDF

As a little bonus, our mimic dropper also opens the decoy PDF.

Run key persistence

Going back to the start of this blog post, we identified that the malware might also set autostart persistence in the registry to survive reboots.

In block 3 above, there are registry modification events that show the malware creating a Run key under `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run`.

Viewing the details of Event ID 4657 (registry value was modified) in Graylog, we see that the key name masquerades as Microsoft Edge Auto Launch. It’s set to execute OriginLegacyCLI.exe (and therefore the EACore.dll TONESHELL backdoor) upon user logon in order to re-infect the system.

We can hunt for registry HKCU\Run key persistence with event IDs 4657 or 4663. Here is an example query using ID 4663 to uncover registry Run key writes from OriginLegacyCLI.exe (Bear in mind that this won’t catch instances where OriginLegacyCLI is renamed or replaced, remove the process_name condition to cover those).

event_code:4663 AND process_name:OriginLegacyCLI.exe AND file_path:/.*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run/

Detections

We recommend the following SigmaHQ rules to detect this attack chain and similar events:

• Mavinject Inject DLL Into Running Process
• Potentially Suspicious Child Process Of Regsvr32 (waitfor.exe added)

We can easily add these rules with Graylog Security. Add the SigmaHQ repository and import all, then search for and enable the rules.

For “Potentially Suspicious Child Process of Regsvr32” you will have to add waitfor.exe to the Image list, like so.

Indicators

These indicators will primarily be useful for hunting past intrusions that went unnoticed. They have little effectiveness in detecting future intrusions by Mustang Panda as threat actors tend to burn or alter their tools and infrastructure between campaigns.

OriginLegacyCLI.exe (legitimate application targeted for sideloading) SHA-256:
91357E6E5A8DB3D9D3B23CE4368425A148683287D917D927EE2BB6E835C87EBE

EACore.dll (modified TONESHELL backdoor) SHA-256:
DC673D59A6A9DF3D02E83FD03AF80E117BEA20954602AE416540870B1B3D13C4

Registry HKCU/Run key (persistence mechanism) Name:
MicrosoftEdgeAutoLaunch_DAC5ED36BBAC4D19045B4BAFA91EF8729

Value:
“c:\programdata\session\OriginLegacyCLI.exe”

www[.]militarytc[.]com:443 (C2 server hostname and port)

193[.]56[.]255[.]179 (C2 server IP address)

In general, look for Mavinject.exe execution and outbound network connections from unexpected Windows programs. Ensure that execution of Potentially Unwanted Programs (PUPs) and unauthorized software is tracked in your environment.

Graylog Detections

Graylog has provided the Sigma Rules and Indicators here to share threat detection intelligence with those not running Graylog Security. Note that Graylog Security customers receive a content feed including Sigma Rules, Anomaly Detectors, Dashboards, and other content to meet various security use cases.

To learn how Graylog can help you improve your security posture, contact us today or watch a demo.

Graylog has always been associated with log management, metrics, SIEM and security monitoring—but it’s also a great tool for creative, low-cost experiments in a home lab. I wanted to use it for real-world sensor data, so I built a DIY temperature and humidity monitor using an ESP-WROOM-32 development board and a DHT22 sensor. This project shows you how to create a lightweight API endpoint on the ESP32, poll it regularly using Graylog’s HTTP API input, and visualize the results in a live dashboard.

I wanted a way to integrate temperature and humidity status into Graylog and send alerts for temperature and low humidity for my equipment room.  Really, my guitar room! I wanted to ensure the humidity was not going below a certain level, potentially causing damage to my prized guitars.

Hardware Used

• ESP-WROOM-32 (ESP32) development board
• DHT22 Digital Temperature & Humidity Sensor
• A few jumper wires
• A WiFi Network for it to connect to
• A Graylog Instance on the same network
• An HTTP API Input configured on Graylog

DHT22 Sensor

The DHT22 data pin is connected to GPIO4. Power comes from the ESP32’s 3.3V rail.

Wiring It Up

The Arduino Code

Arduino is a great way to experiment with many sensors and modules. With most ESP32 boards having WiFi, Bluetooth and a very large community you can almost do anything. You will require the Arduino IED on Windows or Linux to load the code onto an ESP32 Module.  There many aftermarket ESP32 boards so finding the correct board in the IDE can be tricky.  A little trial and error might be necessary.

How This Setup Works

The ESP32 hosts a web server on port 80. When a GET request is sent to “http://ipaddress/sensor”, it responds with the current temperature (in both Celsius and Fahrenheit) and humidity in JSON format. I used the AsyncWebServer, DHT, and ArduinoJson libraries.

Here’s the code running on the ESP32:

#include <WiFi.h>
#include <AsyncTCP.h>
#include <ESPAsyncWebServer.h>
#include <DHT.h>
#include <ArduinoJson.h>

// http://<ESP32_IP>/sensor (how to poll the data)

// WiFi credentials
const char* ssid = "ssidname";
const char* password = "ssidpassword";

// Define DHT type & GPIO
#define DHTPIN 4
#define DHTTYPE DHT22

DHT dht(DHTPIN, DHTTYPE);
AsyncWebServer server(80);

// Define device location
const char* deviceLocation = "Room Location"; // Change this to machine your sensor location

void setup() {
  Serial.begin(115200);
  dht.begin();

  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.println("Connecting to WiFi...");
  }
  Serial.println("Connected to WiFi");

  server.on("/sensor", HTTP_GET, [](AsyncWebServerRequest *request){
    float tempC = dht.readTemperature();
    float tempF = dht.readTemperature(true);
    float humidity = dht.readHumidity();

    if (isnan(tempC) || isnan(tempF) || isnan(humidity)) {
      request->send(500, "application/json", "{\"error\":\"Failed to read from DHT sensor\"}");
      return;
    }

    StaticJsonDocument<200> jsonDoc;
    jsonDoc["location"] = deviceLocation;
    jsonDoc["temperature_C"] = tempC;
    jsonDoc["temperature_F"] = tempF;
    jsonDoc["humidity"] = humidity;

    String jsonResponse;
    serializeJson(jsonDoc, jsonResponse);
    request->send(200, "application/json", jsonResponse);
  });

  server.begin();
}

void loop() {
  // Nothing needed in loop since server runs asynchronously
}

The Output

Once it’s running, you  can visit http://<ESP32_IP>/sensor to get output like this:

{
"location": "Location Name",
"temperature_C": 20,
"temperature_F": 68,
"humidity": 44.1
}

Getting Data into Graylog

To get this data into Graylog, I set up an HTTP API input. This input type is perfect for ingesting structured JSON from IoT devices or scripts. Note: I did not setup advanced token security or any other more secure setup. This could include an API key in your Arduino setup.  This was for basic use and always for best practice, secure your stuff.

Here’s the approach:

• The ESP32 code doesn’t push data—it just serves it in this case.
• I scheduled the input to poll every 6 hours
• It hits the /sensor endpoint, and then pulls the data to Graylog.

Visualizing It in Graylog

Once the data is flowing in, it’s easy to build a dashboard that gives you a real-time view of your environment. I created widgets to show temperature and humidity over time, and also added gauges for current values.

If you want to get creative, you can even trigger alerts for thresholds—like if the humidity spikes or the temp drops below safe levels for a server rack or in my case, the guitar room 🙂

Ideas for Future Expansion

• Add multiple sensors and Graylog inputs for different rooms
• Include motion or door sensors
• Combine sensor data with home firewall logs to correlate physical presence with network activity
• Use anomaly detection to flag environmental shifts

Final Thoughts

This was a fun way to get another project into Graylog alerts. Feeding in structured JSON from a homemade sensor opens the door to a wide range of creative monitoring setups.

If you try something similar or take it further, I’d love to hear about it.

Everyone has a story about that one road trip where traffic got backed up, making people late to the event. When you have network connectivity problems, your information highway gets clogged up, making it difficult for users to access resources efficiently.

While network troubleshooting strategies may seem simple, a lot of nuance and complexity lies in the activities when you dig into your data. Connectivity issues can come from various sources, and they have a wide-ranging impact across internal operations, customer experience, and overall productivity.

By learning the types of problems and how to diagnose them, you can troubleshoot network issues more rapidly. Many tools like Wireshark can be used to help troubleshoot network issues. Central Log Management is Important when identifying application failures, slow web response times, and many other erratic behaviors on the network.

What Is Troubleshooting a Network?

Troubleshooting network issues takes a systematic approach to:

• Identifying and resolving connectivity issues
• Ensuring optimal network performance
• Providing seamless network access

Network, IT, and security teams often collaborate when troubleshooting a network problem because the underlying issues can come from:

• Device hardware
• Software or firmware issues
• Cyber attacks

By documenting each step in the evaluation and resolution process, you can meet compliance requirements and, hopefully, prevent the same problem from happening again.

What Impact do Network Connectivity Issues Have on Businesses?

Network connectivity issues can disrupt business operations by preventing workforce members or customers from accessing resources. These disruptions often lead to:

• Lost productivity: Unable to connect to applications or files required to perform job functions
• Preventing collaboration: Inability to use cloud-based collaboration tools, like messaging applications
• Lost revenue: Interruption of transactions can cause financial issues, like customer church or business disruption
• Customer dissatisfaction: Inability to access services undermines customer trust and loyalty

What are the Types of Network Issues?

Understanding the various types of network issues can act as a good starting point for investigating them and improving your network’s reliability.

1.   Hardware Issues

Hardware issues can lead to connectivity difficulties, performance degradation, and network outages. They often arise from device misconfigurations or hardware failures. Common problems include:

• Overheating components
• Low battery status
• Damaged cables

To maintain your network, you should regularly review the configuration of routers, switches, and cables.

2.   Software Issues

Software conflicts resulting from outdated operating systems, software, or firmware can make applications incompatible. Some ways to prevent these problems include:

• Regularly updating operating systems, software, and firmware
• Scanning for vulnerabilities
• Monitoring network traffic
• Reviewing system logs

3. Bandwidth Issues

Bandwidth limitations can cause network congestion, slow speeds, and increased latency. High-bandwidth activities can overload the network. For example, downloading large files or streaming videos during peak times can slow down the network.

Some ways to prevent these problems include:

• Regular monitoring and configuring of network devices
• Proper bandwidth allocation and utilization

4. Configuration Issues

Misconfigured network devices or software can lead to performance bottlenecks and prevent access to external networks. For example, incorrect IP addressing can create connectivity issues. Regularly reviewing and updating configuration files can mitigate these issues.

5. Firewall and IP Management Issues

Misconfigured firewalls or conflicting security policies can block legitimate network traffic, leading to connectivity issues. However, overly permissive rules or outdated firewall software can expose the network to vulnerabilities, potentially leading to a data breach. For example, bloated firewall rulesets can mean that the device or application takes more time to scan traffic, slowing down the network.

Some ways to prevent these problems include:

• Regularly reviewing firewall configurations
• Optimizing rulesets
• Deleting shadowed or unused rules

6. Security Incidents

Security incidents can impact network performance in several ways. For example, a Distributed Denial of Service (DDoS) attack floods the web server with too many requests which impacts both the server’s availability and the bandwidth on the server’s network. Additionally, security incidents that include data theft may slow down networks as attackers download high volumes of data.

Some ways to mitigate these risks include:

• Monitoring networks for abnormal activity
• Monitoring user account data to identify anomalies
• Requiring multi-factor authentication (MFA) prior to granting network access

5 Network Troubleshooting Best Practices

In complex, connected IT environments, troubleshooting network issues can feel overwhelming. For example, when someone calls the help desk to report that an application isn’t functioning right, investigating the problem can feel overwhelming since it could come from the following:

• Web server where the application resides
• Database that application uses
• Network segment

1.   Centralize Logs

Your logs give you information about activities across your environment. Every device and technology generates logs, so collecting the information in a single location allows you to correlate issues that make your investigation faster. Some locations that you should consider collecting logs from include:

• Hubs
• Switches
• Routers
• Bridges
• Gateways
• Modems
• Repeaters
• Access Points
• Firewalls

2.   Create Dashboards

With all log data in a single location, you can create dashboards that make it easier to gain visibility into what’s happening across your environment. For example, you can correlate information from your network devices, firewalls, and user logins to understand how people are using your network and what abnormal behavior looks like. These dashboards make it easier for you to start an investigation by helping narrow down where the problem lies.

3.   Create Alerts

Part of creating dashboards is high-level visibility. The other half is getting the information available to create alerts that drive investigations across IT and security issues. Since many different factors can lead to a network issue, high-fidelity alerts that make it easier to distinguish between events like software conflicts and DDoS attacks can help you get the network up and running faster.

4.   Conduct Regular Audits

When you regularly audit your network security settings and configurations, you can mitigate network outage risks. Whenever you make changes to the settings and configurations, you should document them because changes can disrupt service, giving you a potential starting point for your investigation.

5.   Adhere to an Escalation Framework

An escalation framework enables you to direct problems to the appropriate expertise levels. For example, you can use the Information Technology Infrastructure Library (ITIL) version 4 framework practices for incident management to create different tiers of service. Tier 1 troubleshooting may handle basic issues, while more complex network problems require people with more experience who can provide advanced intervention.

Graylog Enterprise and Security: Comprehensive Network Insights for Troubleshooting Network Issues

Graylog Enterprise makes it easier for you to navigate through your data and respond to network issues faster. With Graylog Enterprise, you can accelerate quick problem identification and resolution while improving collaboration across different internal teams.

When you need comprehensive insights into your security posture, Graylog Security has you covered. As the only security information and event management (SIEM)/threat detection and incident response (TDIR) platform with native data routing, tiering, and archiving in a single technology, you can level up your security capabilities to identify network-based attacks faster.