Introduction — The Case for Automated Response

If your SIEM only sends alerts, you're leaving value—and security—on the table.

In every incident I’ve investigated, there’s a window between detection and response that determines the scale of impact. In some cases, this delay is a matter of hours, sometimes minutes. But in fast-moving attacks like ransomware deployment, credential stuffing, or lateral movement, seconds might be all it takes to go from contained to compromised.

That’s where automated response comes in.

Rather than waiting for someone to read a Slack message or open their inbox, a well-placed automation can block an attacker IP, disable a vulnerable user, or trigger a workflow instantly. When configured right, automation gives defenders their time back—and gives attackers one chance less.

In this post, I’ll show you how to implement effective, low-risk automated actions in your SIEM. I’ll walk through examples like blocking brute force source IPs, sending adaptive notifications, and integrating webhooks. You don’t need a full SOAR platform to take meaningful action. You just need a reliable alert, a clear goal, and good guardrails.

Let’s explore what’s possible when your alerts don’t just end in a ticket—they end in action.

What You Can Automate (and Why It Helps)

Automated response in your SIEM doesn’t have to mean deploying a full SOAR platform. Even with basic webhook support, you can trigger meaningful actions when alerts match the right conditions. Here's a breakdown of the most common types of automated actions—each with practical benefits and varying levels of risk.

1. Send a Notification (Email, Slack, Teams)

🟢 Low-friction, low-risk

This is the simplest form of automation.

Your SIEM detects something unusual—like a user logging in from a suspicious IP—and sends a message to your Slack channel or a dedicated security inbox.

This doesn't stop anything yet, but it dramatically shortens response time by reaching humans faster (and in the right place).

👉 Example:

• Alert: Office login from TOR node

• Action: Send message to #sec-team on Slack with a link to verify user

2. Trigger a Webhook or API Call

🟡 Medium complexity, highly flexible

If your SIEM supports webhooks or external HTTP calls, you can trigger actions beyond notifications. For instance, you could call a small API you wrote that places an IP in your firewall’s blocklist, or notify a central webhook handler in your detection pipeline.

👉 Example:

• Alert: Multiple failed SSH attempts from a single IP

• Action: Send that IP to an internal API that appends it to iptables ban list via fail2ban

(This is the type I use most, and I’ll walk through it later in the blog.)

3. Execute a Script or Runbook

🟠 Higher risk, more automation

Some systems can run a script directly in response to an alert—especially if you’re using a SIEM combined with an EDR or agent on the machine. This could restart a process, disable a user account, or isolate a host.

While powerful, scripts need rigorous testing. Misfires can create outages.

👉 Example:

• Alert: PsExec lateral movement detected

• Action: Run PowerShell to isolate the machine from the domain

💡 Tip: These are best combined with tagging or human-in-the-loop review at first.

4. Push to a Ticketing System or IR Workflow Tool

🟢 Low-to-medium risk, includes humans

Another useful automation is pushing summarized alert data into your incident response or case management platform (like Jira, TheHive, PagerDuty, etc.). This ensures follow-up, adds context, and lets responders add manual judgment without missing the event.

👉 Example:

• Alert: Phishing link clicked

• Action: Open case in TheHive with log URLs, domain observed, user’s IP

Real-World Use Cases (That Aren’t Too Risky)

Getting started with SIEM automation doesn’t mean plugging your alert pipeline straight into production-blocking scripts. That’s a great way to lock yourself out of an important service—or worse, cause a false positive outage. I like to start with low-friction, high-confidence alerts with clear outcomes.

Here are some use cases I’ve implemented or advised others to adopt first:

🚫 Block Brute-Force IPs Automatically

Brute force attempts are a perfect starter for automation because they’re noisy, repetitive, and usually easy to fingerprint.

🧠 Trigger:

An alert that detects 10+ failed SSH or Windows logon attempts from the same IP within 5 minutes.

⚙️ Action:

Send a webhook to a lightweight API receiving bad IPs, which in turn updates your firewall, fail2ban, or a zero-trust ACL.

✅ Why It Works:

• You can whitelist trusted IP ranges up front

• Blocking via firewall doesn’t affect internal systems

• These attacks are usually automated and follow patterns

🌍 GeoIP + Impossible Travel Notifications

User logs in from Toronto. Three minutes later, they try accessing a sensitive application from Singapore. Unless they have a teleportation pod, something's wrong.

🧠 Trigger:

Alert when two logins are detected from geographically distant locations within an impossible timeframe.

⚙️ Action:

• Automatically send a Slack message or email to the affected user’s manager

• Optionally open a ticket in the incident response system

✅ Why It Works:

• No impact, just visibility

• Helps build context if ongoing investigation is needed

🧪 Tagging or Labeling High-Risk Hosts

Not all automations need to stop attackers directly. You can enrich telemetry by tagging things as risky the moment they're detected.

🧠 Trigger:

Host exhibits lateral movement behavior (e.g., PsExec or WMIExec detection via Sysmon)

Or: Endpoint shows signs of crypto-ransomware behavior

⚙️ Action:

Attach a tag to the host in your log system or asset tracker

Or: write an enrichment flag in Sentinel/Humio to surface in dashboards

✅ Why It Works:

• Non-destructive

• Makes hunting and triage faster

• Builds starting points for weekly reviews or ML training

These ideas are deliberately safe to start with. As you implement these and trust their accuracy, you can progressively increase risk tolerance and expand to more disruptive actions (like user disabling or host isolation).

Hands-On Example: Blocking an IP from a Humio Alert

Let’s walk through a real-world example: a brute force detection alert that automatically blocks the source IP by sending it to a small script via webhook.

This approach works with any SIEM that supports HTTP-based alert actions—Humio makes it simple, but you could do the same with Logz.io, Graylog, or even a homegrown setup.

🎯 The Goal

• Detect failed login attempts coming from a single IP more than 10 times in 5 minutes.

• When that happens, send the IP to a webhook endpoint.

• The webhook triggers a script to block the IP on the firewall.

• The action is logged, monitored, and reversible.

Low risk, high reward.

🗂 Step 1: Create the Detection Query in Humio

In Humio or your SIEM, build the alert like this.

Query Example (Sysmon/Winlogbeat logs):

event.code=4625 
| groupby([beat_agent.hostname, winlog.event_data.IpAddress], function=count()) 
| where([count > 10]) 

This detects 10+ failed login attempts from the same source IP on the same host.

🔍 Tips:

• Avoid internal IPs or your own jump-boxes by filtering with where(not winlog.event_data.IpAddress in (your allowlist))

• Tune down to 5 attempts in testing, tune up to 20+ in prod

⚠️ Step 2: Configure the Alert Action

In Humio:

• Go to Alerts

• Choose your query, click “Create Alert”

• Set threshold = 1 (fires whenever there’s a matching group)

• Throttle: >5 mins per host+IP tuple

Action Setup (Webhook):

• Type: “HTTP POST”

• URL: https://your-automation-host/api/block-ip

• Payload:

{
  "hostname": "{{beat_agent.hostname}}",
  "ip": "{{winlog.event_data.IpAddress}}"
}

✔️ Set content-type as application/json

✔️ Secure it with an API key in the header, or only allow network-restricted source IPs

🛠 Step 3: Write the Webhook Script

Here’s a very simple example in Python (Flask-based API):

from flask import Flask, request, jsonify
import subprocess
import logging

app = Flask(__name__)
logging.basicConfig(filename='ipblocks.log', level=logging.INFO)

@app.route('/api/block-ip', methods=['POST'])
def block_ip():
    data = request.json
    ip = data.get('ip')

    # Validate the IP (simple check)
    # This is not enough to safeguards against RCE.
    # TODO: add more checks!
    # This is only an example!
    if not ip or '..' in ip or '/' in ip or ';' in ip or '&' in ip or '|' in ip:
        return jsonify({"error": "invalid IP"}), 400

    # Block the IP using iptables (Linux)
    # One would imagine a CTF challenge here!
    cmd = f"iptables -A INPUT -s {ip} -j DROP"
    subprocess.run(cmd, shell=True)

    logging.info(f"Blocked IP {ip} via automation")
    return jsonify({"status": "blocked", "ip": ip})

💡 Save and run this on a secured automation server. Rotate IPs out after X days or add removal logic.

Alternatives:

• Use UFW, fail2ban custom chains, or cloud firewall/blocklist APIs (e.g., AWS, Cloudflare)

• If you don’t want actual blocking: just log or simulate the response action!

🔎 Step 4: Monitor & Tune

Now that you’ve automated your first response, be sure to:

• Log every action (separate audit file or SIEM event)

• Monitor alerts for false positives—adjust thresholds

• Use alert “Preview” and dry runs to test

• Sanitize inputs and control webhook access

Optional additions:

• Store blocked IPs in SQLite or Redis to allow removal later

• Add Slack/Email alerts from the script for visibility

🔐 Bonus: Add a Safety Switch

Build a toggle in the script (“MAINTENANCE_MODE=True”) that allows you to disable enforcement instantly. Or only allow from specific alert sources (e.g., trusted Humio instance UUIDs).

🎉 Boom — you’ve now built an early warning system that defends itself.

Up next, we’ll talk about how to scale this approach and avoid common mistakes.

Subscribe now

Best Practices & Guardrails

Before you get too deep into automating blockade systems and forensic scripts, let’s cover the most important part of any automation effort: treating it like production code.

Automated actions affect your systems—sometimes permanently. Without proper guardrails, a bug in detection or a misfiring rule could put your security team in the spotlight for all the wrong reasons. Here's how to do it right.

✅ 1. Start with Notifications, Then Actions

The temptation to go straight from alert to action is real—but don’t skip the dry run phase.

Always begin by triggering a notification or logging-only action, and monitor the alert fidelity over time. Only after verifying that your false positive rate is low should you consider moving to blocking or remediation automation.

📝 Pro tip:

“Log + Notify + Review” for a week before enabling the final blocking logic.

🛡 2. Whitelist Known Good Behavior

Always protect critical systems, known testers, and internal IPs from being impacted by automated actions unless absolutely required. You’ll want to include a whitelist—either inline or backend-controlled—which the automation must check before enforcement.

Examples:

• Don’t block your VPN endpoint

• Don’t isolate your own monitoring agent

• Don’t trigger changes on development or staging logs

🧪 3. Log Everything the Automation Does

If your automation blocks an IP, disables a user, or restarts a service, you need a clear audit trail of:

• What triggered the action

• When it ran

• What was actually done

• Who or what performed it

• Whether it succeeded or failed

📁 Tip: Log all of this to your SIEM itself.

Bonus: Create a dashboard of recent automation actions to catch errors early.

🔁 4. Add Rate Limiting and Throttling

Just because 50 alerts fire at once doesn’t mean you want 50 API calls and actions firing simultaneously.

Add throttling—or use your SIEM’s built-in alert throttle—to avoid alert storms. This ensures you don’t overwhelm your firewall with too many rule changes or bounce through rate limits on an external system.

📏 Example:

Only execute the action once per unique IP per hour, or once per system per 10 minutes.

🔂 5. Make It Reversible (and Pauseable)

You WILL make a mistake. Your automation might react to a misparsed event or a data ingestion bug.

Plan for rollback. Here’s how much:

• Can you remove a blocked IP with a single call?

• Is there a safe list to re-allow access?

• Can you “pause” automation with one toggle if you’re under pressure?

Most mistakes in security are made in fear. Don’t let your automation increase panic—build kill switches and clear recovery steps.

Automating threat response means trusting your SIEM’s alerts with real power. These best practices are like a flight checklist: they ensure it flies where and when you want it to—and lands safely when it’s done.

Up next, let’s look at the typical automation pitfalls I see in the wild—and how you can avoid them.

Common Pitfalls to Avoid

When I talk to teams about SIEM automation, they’re usually excited. And with good reason—automation turns alerts into actions and allows teams to scale. But I’ve also seen well-meaning automation wreak havoc because a few basic rules were overlooked.

Here are the most common mistakes I see when teams launch automated responses too early—or without thinking through the consequences.

🔁 Acting on Noisy Alerts

This is the classic mistake: building automations on top of alerts that still generate false positives. If your brute force alert is misfiring, feeding it into an auto-blocking script will just create chaos.

You might end up:

• Blocking your own security scanner

• Disabling perfectly legitimate logins

• Filling your firewall ruleset unnecessarily

🛑 Fix it first: Make sure your detection logic is solid, tuned, and meaningful before giving it power.

💡 Pro tip: Review fired alerts over 7–14 days before moving to response.

🌪 Forgetting Alert Throttling

Without rate limiting, a flood of log-ins from one device, a SIEM parsing bug, or log ingestion issue could trigger hundreds of simultaneous actions.

I once saw a mis-parsed Linux event trigger 300+ alerts in under 60 seconds—which then triggered an overload in the iptables automation service.

✔ Add guardrails:

• Alert throttling (native in many SIEMs)

• IP block counters (rate-limits per source)

• Timeout queues on your action scripts

👁️ No Visibility on What’s Happening

If you're not logging the actions taken—or you’re only logging success—you’re working blind.

Imagine:

• You blocked 42 IPs… but which ones?

• A script failed to run… was it retried?

• Someone paused your webhook host… and now no action is running

🌟 Always log:

• What triggered the action (alert details)

• What was attempted (API call, command)

• The result (success/failure)

Put this in a shared log store, or even feed “meta events” to the SIEM itself.

🔒 No Authentication or Input Validation

If your webhook is listening for JSON from anywhere—make sure it's authentic.

Imagine an attacker figures out your webhook URL… and submits their own IP with your same automation call. Or worse, they inject shell code as part of a manipulated payload.

Secure your endpoints:

• API keys or HMAC validation

• Restrict source IP to the SIEM only

• Sanitize all fields before running commands

If you're passing variables into a shell script, validate and escape everything.

🧨 Over-Automating Detonation

Some teams go all-in: "If this alert fires, disconnect the user, disable the account, and terminate the EC2 instance."

That’s tempting, but only safe at maturity. Without escalation logic, human review, or an understanding of business impact, automation might react more aggressively than intended.

Instead:

• Automate gently (alert, log, escalate)

• Use tagging, enrichment, and visibility automation

• Add human-in-the-loop steps before destructive actions

You can scale trust with automation—but only if everyone trusts it over time.

TL;DR — Don’t Put a Bazooka on an Alert Until it Knows What It’s Aiming At

Automation is powerful—but only when it obeys the rules of reliability, auditability, and control. Treat your response logic like a developer treats production code: observability, rollback, and safety nets should always be included.

Where to Go From Here

You’ve built one automation, logged its behavior, and avoided tripping your own firewalls—great work. Now what?

One of the strengths of building lean, scriptable SIEM automations is that you can grow them gradually. The goal isn’t to automate everything. It’s to automate the right things consistently and recoverably.

Here’s how to take your setup further:

🧰 1. Expand Your Webhook Handler

Don’t let your blocking script do just one thing. You can support more actions using conditional logic:

• Block an IP

• Put a tag in a shared asset tracker

• Write a note into a shared Google Sheet or case system

• Notify an MDR or response team externally

• Populate a blocklist file or feed

Small automations like this scale well and create glue between tools.

🛠 Tip: Build modularly — write clean, multi-source-capable input handlers and you won’t need to rebuild later.

🎩 2. Integrate with Your Ticketing or Workflow Tool

If you’re not ready to block things automatically, pipe your alert context into your response platform.

Examples:

• Create a Jira ticket for phishing-link clicks

• Trigger a case in TheHive for suspicious process chains

• Send markdown-formatted incident summaries to Mattermost

This acts as “automated assurance”—you won’t forget the incident, and responders can add human judgment if needed.

🔄 3. Enrich Alerts — Not Just Respond

Your SIEM should grow more informed over time.

When an alert fires, automation doesn’t have to only take action. It can:

• Append GeoIP context based on source IP

• Mark an asset’s risk score in the SIEM

• Add domain reputation or VirusTotal score

• Link to previous similar alerts

Automation = context at machine speed.

🧠 4. Create a Lightweight “SOAR Without SOAR”

If you’re not buying a full commercial SOAR (Security Orchestration, Automation and Response) platform, you’re not alone.

With the right stack, you can build your own SOAR-lite with:

• Your SIEM alerting engine (Humio, Elasticsearch, etc.)

• A webhook layer / action handler (Flask, Lambda, etc.)

• Basic storage (SQLite, Google Sheets, JSON-logs)

• Dashboards or markdown playbooks

This gives you enough control and extensibility for most use cases—especially in a small or mid-size team.

📝My blog used this model before the move to Substack. Works well. Cost? $0.

🔭 5. Experiment, Measure, and Refine

Great SIEM automations are never built in one pass. I recommend:

• Logging every action, even if it “does nothing”

• Holding monthly reviews of automation performance (e.g. top 10 triggered rules)

• Keeping a chart of false positives vs. enforcement success

• Versioning your detection + automation rules together

This turns security automation into a feedback loop—not just a trigger.

Conclusion

Security automation isn’t reserved for large enterprises or teams with a SOAR budget. You don’t need to over-invest, overbuild, or over-trust untested systems.

With just a few hours and the right SIEM alert, you can build useful automations that:

• Respond faster to obvious threats (like brute-force attempts)

• Help defenders focus on high-value work

• Reduce fatigue from repetitive incidents

Whether you're defending your home lab, managing detection pipelines for clients, or running SecOps in a growing organization, your SIEM can do more than notify—it can act.

Start with one use case. Get it right. Monitor its behavior. And when you’re confident, scale it up to your next alert. You’ll be amazed at how quickly “just an alert” becomes something that actually helps you sleep at night.

If you’d like to explore more, I’ve also written about detecting PsExec lateral movement, configuring alert thresholds, or tuning SIEM correlation rules to reduce false positives.

☑ Build one automation. Review. Repeat.

🎯 Want more hands-on detection walkthroughs and security strategies?

Subscribe now

to get the next blog posts as I publish them!

—

💬 Did you try an automation and learn something from it? Share it in the comments! I’d love to hear it.

Leave a comment

—

📬 Need help building detection + action pipelines for your team? I run detection engineering for MDR platforms and help teams implement lightweight but effective automation. Feel free to reach out.

🧡 Donation

If you like my blog and my posts, please consider donating!

Imagine this: each minute of reading a post takes about 1–2 hours to create!

Donate 🧡

Benefits of Elasticsearch

Customers and the open-source community enjoyed a variety of services offered by Elastic through its products (like Elasticsearch). Elasticsearch is a distributed search engine providing a number of features that make data processing more efficient and effective while maintaining its ability of scalability, speed and resilience. Elasticsearch through its partner product Kibana, Beats and Logstash provide a simplified way of data visualization, ingest and reporting. The other very reliable feature is its distributable nature which allows it to handle a huge size of data without compromising performance. It provides a real-time search platform which provide the shortest time possible when a user makes a search.

The open-source community contributes much on this product through various ways like providing codes and documentation, bugs report, write of tutorial, blogs etc. Elasticsearch was providing the code under the Apache v2 license. All this makes everyone feel the meaning of "open" in "open-source". A report by macrotrends shows that the company net worth from 2018-2020 is estimated as $14.33B. This is an indication of how big the customer base is, and the revenue generated help contribute to the open-source community.

The context

On February 27’th 2018, the Elastic company CEO, Shay Banon, delivered a message on their website that mealy read as an announcement for the release of the new repository for their products on the version 6.3. A new folder in the code, named X-Pack, was created and all the proprietary product code moved to that folder under the elastic license which many customer and open-source code community believed that was a way of facilitating greater collaboration.

He affirmed that their products had to be open source hence providing the opportunity to reach so many people who can provide their contribution through various ways and even enable a push for what was seen, at the time, as a pipe dream. He even committed himself that as a company they will ever maintain to be open as a way of building their business.

However, on January 14'th 2021, Shay Banon announced that they were moving away from the truly open-source license (Apache v2) to the newer Server Side Public License (SSPL). The open-source community was shocked to realize that in order to use the Elastic products, you now had to agree to the terms and conditions of the SSPL or the elastic license. The former as new as it looks deprive the organizations of their intellectual property rights when observed from the spirit of "open source" in the business environment:

By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal.

https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearch-and-kibana-are-now-business-risks

From Elastic's website:

Why this move to the new SSPL Elasticsearch license

The elastic company felt that “enough is enough” and that they should protect its product from cloud service providers whose intention was to capture the value of the same product while contributing nothing to the open-source community, as expressed by Eliot Horowitz, CTO and co-founder of MongoDB. Together with elastic’s CEO, they felt that companies like Amazon that are providing this product as a Software as a Service, without the knowledge or the consent of the Elastic company while misleading the community that they are, is "not ok". They tried and didn't succeed to resolve this issue through courts.

A new hope

In response, AWS announced that it will create and maintain an Apache v2 licensed fork of Elastisearch and Kibana. They further expressed that the choice to fork a project was the right path forward when the community needs are diverging. To emphasize it, they stated that they are in the game for a long haul and ready to work in a way that will create a healthy and sustainable open-source practice.

Logz.io joined the fray and expressed their concern as to why they think the change of license from Elastic, at the expense of the open-source community, is “not OK”. In a retaliatory tone, they gave their objective to have projects driven by multiple organizations rather than a single commercial entity and plans to collaborate with such organizations (like Amazon) that believe that those products, Elasticsearch and Kibana, need to stay open source.

References

• https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearch-and-kibana-are-now-business-risks

• https://www.elastic.co/blog/doubling-down-on-open

• https://medium.com/@AIMDekTech/what-is-elasticsearch-why-elasticsearch-advantages-of-elasticsearch-47b81b549f4d

• https://www.elastic.co/blog/why-license-change-AWS

• https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

• https://logz.io/blog/open-source-elasticsearch-doubling-down/

• https://mjg59.dreamwidth.org/51230.html

2021-04-18 Update

AWS announced they will be actively developing OpenSearch and OpenSearch Dashboard to replace Elasticsearch and Kibana, respectively. Both these new products will be fully opensource under the Apache 2.0 License.
Source: https://aws.amazon.com/blogs/opensource/introducing-opensearch/

🧡Donation

If you like my blog and my posts, please consider donating! Imagine this: each minute of reading a post takes about 1-2 hours to create!

Donate 🧡

In this post I’ll explain the CIS controls and how they can be used to start securing an enterprise.

When you’re in a medium or big environment and the maturity level of the InfoSec is around zer0, it’s hard to decide where to start in securing your environment. Do we need to update the sys…

Read more

You’ve hardened all you could on your servers or computers, you have a strong password with MFA, you update regularly or automatically everything and are wondering what can be done next?

Like you probably know, you can never be 100% protected and there is always a way criminals can find to access private information. For those who tells me they are 100% secure, here is an example:

You have a secure WordPress website at www.mysite.com which has nice plugins to secure it, you maintain it up to date and you have MFA. You then go in a public cafe to make some changes to your website. You enter your WordPress URL in your browser, get the login window, enter your password + your MFA and get access to your website. You then make some changes and everything works as normal. Then a few days later your site gets defaced, or worse. What happened?

What you missed here is that an attacker in the same cafe as you was able to change the IP returned when you did a DNS query for your domain (either through MITM or by changing the DNS Server in the router config). He then redirected you to a new domain: www.rnysite.com. This new domain is owned by the attacker and directs you to a sever that runs Modlishka. This attacking tool essentially proxies all your traffic to your real website www.mysite.com, even validating your password + MFA and making the changes you ask for, but he also makes a copy of all the traffic, taking your cookies and password. Although he doesn’t have your MFA, he now has your cookies. Oh and if that’s not enough, it’s possible now to brute-force the TOTP seed with Hashcat with only 2 TOTP token. (Here is a definition of Brute-force attack)

So now what?

Well, here comes logging, aggregating, correlating and alerting — also known as a Security Information and Event Management, or SIEM.

But what is a SIEM? As Varonis puts it:

Security Information and Event Management (SIEM) is a software solution that aggregates and analyzes activity from many different resources across your entire IT infrastructure.

SIEM collects security data from network devices, servers, domain controllers, and more. SIEM stores, normalizes, aggregates, and applies analytics to that data to discover trends, detect threats, and enable organizations to investigate any alerts.

Source: https://www.varonis.com/blog/what-is-siem/

…

Now that we established what is a SIEM and why it is needed, how to we get started with this?

Well, to get started using a SIEM, you can read my blog posts on the subject! My goal is to make it easy to understand and accessible to anyone with some IT experience.

Next post: SIEM 101 — Introduction

Feel free to leave your comment down here for any questions or comments.

Donation

If you like my blog and my posts, please consider donating! Imagine this: each minute of reading a post takes about 1-2 hours to create!

In the following days, I’ll write a few blog posts explaining how to easily learn to use a Security Information and Event Management, or SIEM.

Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/

But what is a SIEM? As Varonis puts it:

Security Information and Event Management (SIEM) is a software solution that aggregates and analyzes activity from many different resources across your entire IT infrastructure.

SIEM collects security data from network devices, servers, domain controllers, and more. SIEM stores, normalizes, aggregates, and applies analytics to that data to discover trends, detect threats, and enable organizations to investigate any alerts.

Source: https://www.varonis.com/blog/what-is-siem/

To do this, I wrote the post SIEM 101 — Initial setup where I explain how to create an account on Logz.io; they offer a free account where you can send up to 1 GB / day of logs to try their platform. Time needed: around 2 minutes.

Still in the post SIEM 101 — Initial setup, I then explain how to send your logs there, whether you’re on Windows or on Linux. Time needed: around 5–10 minutes.

After that, I’ll explain the basic usage of Logz.io, how to search logs, how to create an alarm, etc. Time needed: around 30 minutes.

When all this is done, the scene will be in place to start writing blogs on detection cases, for example: receive an alert if Windows is brute forced, receive an alert if a failed logon happened on your WordPress server, etc.

I’ll eventually talk about the scripts I developed that uses Logz.io to automatically block bad IPs on my servers.

For the most advanced users, you’ll then be able to discover some useful tools the community provides, like the Sigma rules.

Follow me in my next post: SIEM 101 — Initial setup

Feel free to leave your comment down here for any questions or comments.

Donation

If you like my blog and my posts, please consider donating! Imagine this: each minute of reading a post takes about 1-2 hours to create!

A few years ago, I was on the defense team when a pentest was ongoing on one of our website. This website, coded in C#, was hosted on Windows and had Windows Defender activated.

During the pentest, the attacker had access to the CMS. He discovered that he could upload his own plugins, giving him Remote Code Execution (RCE) on the server. Happy with this discovery, he started his C&C server (it was PowerShell Empire 2 at the time), crafted a payload and launched the result in a C# wrapped plugin and then… nothing.

As some of you may know, C#, PowerShell and Defender all love to work together. That’s because the .NET framework is now tightly integrated with Windows Defender. When sending the payload, Defender could see and block the attack.

So all the attacker had to do was to modify his payload until it passed all the checks Defender does. After a few hours, he had a complete reverse shell (although restricted to the IIS user).

From the defense point of view, the fact that Defender did his job is perfect. But the fact that we didn’t know Defender blocked a file-less attack and we only learned it when we receive the report should be considered a disaster. It means your AV is useless because an attacker has all the time he needs to craft his attack.

From this point, the next steps where clear, we needed to receive an alert when a virus was detected. And maybe on other suspicious behavior? That’s when I discovered what is a SIEM!

If you wan’t to know more about what is a SIEM and how to use it, you can read my blog posts on the subject starting with: SIEM 101 — Introduction

Feel free to leave your comment down here for any questions or comments.

Donation

If you like my blog and my posts, please consider donating! Imagine this: each minute of reading a post takes about 1-2 hours to create!

Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/

This is the second post of the series “SIEM 101″ where I explain the basics of a SIEM, from installation to simple usage. You can see the previous post SIEM 101 — Introduction.

I decided to write the series using Logz.io because they offer an easy to use platform with a free 1GB/day trial with a smooth learning curve. Of course they don’t offer all the features in the free version and some crucial features for a SIEM are missing, but this is perfect to get started with a SIEM! For the Splunk fans, I’ll probably write a blog post about why I don’t recommend it often and why I recommend an Elasticsearch based SIEM most of the time.

Read more

Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/

For this post, I assume you’ve read my SIEM 100 series where I explain the basics of Logz.io. I’ll be using the stack I created in this series to demonstrate what to do.

PsExec is a tool provided by Microsoft in the Sysinternals suite: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
Like they explain:
 

PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec’s most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems.

https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

PsExec can be use as an adversary to pivot between computers and/or elevate privileges. It is rather easy to detect when executed on a monitored endpoint, but what happens when a remote computer not monitored use it to connect to a monitored endpoint?

It turns out it can be detected by looking for a chain of 3 events, distinctive of PsExec behavior when remote connecting.

Read more

Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/

For this post, I assume you’ve read my SIEM 100 series where I explain the basics of Logz.io. I’ll be using the stack I created in this series to demonstrate what to do.

Why we need to detect Windows bruteforce

When we have a lot of Windows machine in our environment, it can be useful to be able to detect a bruteforce on a machine, be it over RDP or not. For example, with this Use Case, we could detect an attacker trying to login on a sensitive computer or trying to pivot between machine.

This Use Case is really simple so it’s rather easy to develop and test. But it’s also prone to false positive, so it’s a good Use Case to learn to reduce the false positives.

How

Read more

Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/

For this post, I assume you’ve read my SIEM 100 series where I explain the basics of Logz.io. I’ll be using the stack I created in this series to demonstate what to do.

Sysmon is a tool provided by Microsoft in the Sysinternals suite: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon.  

Like they explain:

System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network.

Read more

Note: In this post I use Logz.io for my examples, but I recently switched to Humio. For more details: https://www.tristandostaler.com/why-i-switched-from-logz-io-to-humio/

This is the third post of the series “SIEM 101” where I explain the basics of a SIEM, from installation to simple usage. You can see the previous post SIEM 101 — Initial setup.

Read more

Information Security, Cybersecurity, IT security. We’ve all heard and read them in interchangeable ways, these synonyms all aim to define what is security. But most of them imply assumptions harmful for the Information Security domain. Let me explain.

What we try to do

Generally, when we, or often the media, use the term “Cybersecurity”, we want to describe the idea that we want to be secure against some kind of “hacker”. Most people who use this term imagine a “hacker”, in a black hoodie, in front of a screen full of green scribble. But this idea misses the point of what really is Security, or as I prefer to say, Information Security, or InfoSec.

What a bad actor, often named “hacker”, really want to do is to gain access to information that he/she wouldn’t normally have access otherwise to reach a goal.

In a ransomware attack, the goal is to keep you from having access to this information and extort money from you. In a phishing attack, the goal could be to steal credentials, which is a kind of information, to use them or sell them.

So once we understand what the bad actor wants, we understand what we need to protect. At the highest level, the goal is Information. Hence the word “information” in “Information Security”. The security part imply the idea that we want to protect this information against all kind of attacks.

Why it’s a problem

The problem with the words “Cybersecurity”, “IT security” and other similar terms is that they imply that the security must be done at the technology level: the computers, the servers, the firewalls, the switches, etc. While it is important to secure these technologies, the global strategy needs to be way larger.

For example, no technology can help us against the CEO fraud if an untrain employee falls for it. The problem in this specific case is the lack of training. Training is not a technological solution but it is one of the most effective strategy to protect the business.

If we try to reduce the security problem to only the technology, we’ll fail miserably.

The reason these terms are harmful to the domain is that they create this idea in the mind of the leaders that security is an IT problem. So it often falls in the hands of an IT officer, like the CTO. Most businesses don’t have a CISO, and those who do have him/her under the IT department. I could write a complete post on why this is a bad idea.

What should we do

This is a business culture problem and this is where we need to start the work. Businesses that invest in a Security culture often thrives even more than the ones that put millions on technologies.

So it is more than time that we start talking about this domain by naming it “Information Security“!

Note: I wrote “hacker” between quotes when talking about bad actors because this term became pejorative. Initially, a hacker is only someone who finds a way around some limitations, with good or bad intentions; mostly goods. For example, my reading light is too bright and I can’t dim it enough; so I put black tape on it to cover about 80% so I get just enough light. That’s hacking applied to something else than technology. It’s a ridiculous example to demonstrate my idea.

As explained in wikipedia:

The controversy is usually based on the assertion that the term originally meant someone messing about with something in a positive sense, that is, using playful cleverness to achieve a goal. But then, it is supposed, the meaning of the term shifted over the decades and came to refer to computer criminals

Source: https://en.wikipedia.org/wiki/Hacker

Note 2: because of the way SEO works, I’ll hack my way to the top results by placing terms like “Cybersecurity” in my blog from time to time 😉

Feel free to leave your comment down here for any questions or comments.

Donation

If you like my blog and my posts, please consider donating! Imagine this: each minute of reading a post takes about 1-2 hours to create!

What is SolarWinds Orion

SolarWinds is a US based company. They have clients worldwide. One of the products they offer is Orion. This tool does a lot of things, but the main feature that interest us is that it provides the ability to monitor your infrastructure. To do this, you need to install the Orion agent on one of your servers. This agent is installed with high privileges and is able to login on most of your infrastructure to gather metrics like CPU, RAM, etc.

What’s the hack

At the moment I am writing these lines, it is unclear how SolarWinds got hacked. What we know is that it was perpetrated by an APT (Advanced Persistent Threat, a term used to describe high profile malicious hacker groups) probably backed by Russia. In other words, they got hacked by a highly skilled group of hackers with deep pockets.

Read more

What is a Zero Trust Architecture

A Zero Trust Architecture (ZTA) is an Information Security architecture based on the idea that a network shouldn’t have inherent trust on the internal boundary. Many enterprise networks are designed like an egg where they have a rather strong and robust external shell, but once inside the shell, everything is lax; it needs only a little needle that is able to break through the shell to wreak havoc inside.

Read more

WordPress is one of the most popular CMS and website server in the world. It handles “more than 30%” of the websites on the internet. Because of this, bad actors are really interested in finding ways to get control of them.

One of the most easy way for them to achieve this is by bruteforcing the login for common username and password combinaisons, including from past leaks. This is a working strategy because by default WordPress doesn’t protect against bruteforce attacks.

How do we detect a WordPress bruteforce attack

In the WordPress world, there are many ways to handle bruteforce attacks, as this is rather simple to detect. But because we are in the SIEM series, I’ll talk about how to detect the attack using a SIEM.

Read more

Source: https://twitter.com/OffenseTeacher/status/1351927187180572673

Some background

Some background are required to understand his response.

First, it is important to know that …

Read more

Note: I used “Cybersecurity paths” , “where to start in cybersecurity” and “Cybersecurity jobs” just so I get good SEO results. To know why, you can read my post Information Security Synonyms.

If you Google “Cybersecurity paths”, “Cybersecurity career”, “Cybersecurity jobs” and other similar terms, you’ll find an …

Read more

Lockbit is a “Ransomware as a Service” which means you can buy a powerful ransomware, launch it in your target’s network and Lockbit will take care of the rest. They even have support teams to assist victims into the payment and recover…

Read more

Today I’m announcing a brand new addition to my Substack publication: Tristan’s Cybersecurity Substack subscriber chat.

This is a conversation space exclusively for subscribers—kind of like a group chat or live hangout. I’ll post questions and updates that come my way, and you can jump into the discussion.

Join chat

How to get started

1. Get the Substack app by clicking this link or the button below. New chat threads won’t be sent sent via email, so turn on push notifications so you don’t miss conversation as it happens. You can also access chat on the web.

Get app

2. Open the app and tap the Chat icon. It looks like two bubbles in the bottom bar, and you’ll see a row for my chat inside.

3. That’s it! Jump into my thread to say hi, and if you have any issues, check out Substack’s FAQ.

In recent years, ransomware has become an increasingly prevalent and dangerous cybersecurity threat. These malicious attacks involve encrypting a victim’s data, rendering it inaccessible until a ransom is paid9, often in cryptocurrency. But what makes ransomware so successful, and how has it evolved into one of the most feared forms of cybercrime?

Unders…

Read more