Introduction

In the ever-evolving landscape of cybersecurity, keeping up with the latest technologies and solutions is crucial for protecting an organization’s digital assets. Among these technologies, detection and response solutions have become increasingly significant. Terms like EDR, XDR, NDR, and MDR are frequently used, but what do they actually mean, and how do they differ? This comprehensive guide will provide a detailed overview of these detection and response (DR) solutions, compare their features, and help you understand when to use each one.

Detailed Overview of Detection and Response Solutions

EDR (Endpoint Detection and Response)

Endpoint Detection and Response (EDR) focuses on detecting and investigating suspicious activities and threats on endpoints, such as desktops, laptops, and mobile devices. EDR solutions provide continuous monitoring, threat detection, and automated response capabilities. Essentially, EDR acts as a “Next-gen antivirus” because legacy antivirus (AV) solutions can be bypassed too easily. Key features include:

• Real-time monitoring of endpoint activities.

• Threat detection using behavioral analysis and machine learning.

• Incident response automation.

• Forensic capabilities for deep-dive investigations.

• Integration with other security tools for a holistic defense approach.

XDR (Extended Detection and Response)

Extended Detection and Response (XDR) is an evolution of EDR that integrates multiple security products into a cohesive system, providing broader threat detection and response capabilities across various environments. XDR solutions unify data from endpoints, networks, servers, and other sources. Key features include:

• Unified threat detection and response across multiple security layers.

• Enhanced visibility and correlation of security events.

• Centralized management and automated workflows.

• Improved threat detection with advanced analytics and machine learning.

• Seamless integration with existing security infrastructure.

NDR (Network Detection and Response)

Network Detection and Response (NDR) solutions focus on monitoring and analyzing network traffic to detect and respond to threats. NDR provides visibility into network activities, helping identify malicious behavior and potential breaches. Key features include:

• Continuous monitoring of network traffic.

• Detection of anomalies and suspicious activities.

• Real-time threat intelligence and analysis.

• Automated incident response and containment.

• Integration with other security tools for comprehensive protection.

MDR (Managed Detection and Response)

Managed Detection and Response (MDR) services extend beyond traditional DR solutions by adding a layer of expert management and monitoring. MDR providers offer 24/7 threat monitoring, detection, and response, leveraging a combination of technology, processes, and human expertise. MDR makes use of EDR, XDR, NDR technologies, and more. Additionally, MDR looks at multiple sources such as endpoints, networks, cloud environments, and other IT infrastructure. Another emerging term for MDR that reflects this multi-source capability is MXDR (Managed Extended Detection and Response). Key features include:

• Proactive threat hunting and monitoring.

• Expert analysis and incident response.

• Regular reporting and compliance assistance.

• Rapid threat containment and remediation.

• Access to a team of cybersecurity experts.

• Monitoring of cloud services and infrastructure.

Comparing EDR, XDR, NDR, and MDR

While all these solutions aim to enhance an organization’s security posture, they differ in scope, capabilities, and application. Here’s a detailed comparison:

• Scope:

  • EDR: Focuses on endpoints.

  • XDR: Integrates data from multiple security layers (endpoints, network, cloud, etc.).

  • NDR: Focuses on network traffic.

  • MDR (or MXDR): Managed service covering endpoints, networks, cloud services, and more.

• Capabilities:

  • EDR: Real-time endpoint monitoring, threat detection, automated response.

  • XDR: Unified threat detection, centralized management, advanced analytics.

  • NDR: Network traffic analysis, anomaly detection, real-time response.

  • MDR (or MXDR): Proactive threat hunting, expert analysis, managed response.

• Use of Resources:

  • EDR: Requires in-house security team.

  • XDR: Requires integration and management of multiple security tools.

  • NDR: Focuses on network security, often used alongside other DR solutions.

  • MDR (or MXDR): Managed by external experts.

When to Use Each Solution

Choosing the right detection and response solution depends on your organization’s specific needs, resources, and security posture. Here are some scenarios and use cases:

• EDR: Ideal for organizations with a dedicated security team that needs robust endpoint protection and response capabilities.

• XDR: Best for organizations seeking a unified security approach, integrating multiple data sources for comprehensive threat detection and response.

• NDR: Perfect for organizations prioritizing network security, needing detailed traffic analysis and rapid incident response.

• MDR (or MXDR): Suitable for organizations with limited in-house expertise or resources, benefiting from managed services and expert support.

SOC vs. MDR: Key Differences

While both a Security Operations Center (SOC) and Managed Detection and Response (MDR) are crucial for an organization’s cybersecurity, they differ significantly in their structure, scope, and functionality:

Security Operations Center (SOC)

• Definition: A centralized in-house function that continuously monitors and improves an organization’s security posture.

• Features: 24/7 monitoring, in-house team, incident response, threat intelligence, customizable.

• Pros: Complete control, tailored to organizational needs, direct communication.

• Cons: Resource-intensive, requires expertise, scalability challenges.

Managed Detection and Response (MDR)

• Definition: An outsourced service providing threat detection, response, and monitoring.

• Features: 24/7 threat monitoring, proactive threat hunting, expert analysis, incident response, regular reporting.

• Pros: Cost-effective, access to expertise, quick deployment, scalable.

• Cons: Less control, dependency on vendor, potential communication challenges.

Differences Between MDR and EDR, XDR, NDR

In EDR, XDR, or NDR solutions, detection and response are primarily automated with limited or no access to experts, no customization of response processes, no integration of custom sources, and no dedicated incident response team. Conversely, MDR (or MXDR) provides human expertise, tailored response processes, integration of custom data sources, and a dedicated incident response team.

Choosing Between SOC and MDR

The decision between an in-house SOC or MDR services depends on factors like budget, resources, control needs, scalability, and complexity. Organizations with limited budgets or expertise may benefit from MDR, while those needing full control and customization might prefer an in-house SOC.

Conclusion

Understanding the differences between EDR, XDR, NDR, MDR, and the distinction between SOC and MDR is crucial for making informed decisions about your organization’s cybersecurity strategy. Each solution offers unique benefits and capabilities, tailored to specific security needs. By selecting the right detection and response solution, you can enhance your organization’s ability to detect, respond to, and mitigate cyber threats effectively.

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.

First step: open an account

The first thing to do is to open an account on Logz.io. They offer to open an account using your google account, or to register with an email. For this demo I’ll use the google SSO option. So head over to Logz.io and register: 

https://app.logz.io/#/login

Next, click on “Sign in with Google”: 

You’ll get redirected to the Google SSO. Select your existing account, login or create an account. I’ll let you figure this part out.

Then, once back on the Logz.io website, you get a Sign up page. Fill out the details and click “Create Account”:

Note: It is smart to choose a region close to where you live to get better bandwidth when sending logs.

That’s it, your account is ready to receive logs! When you login, you can follow their tutorial if you want to. The next step in this post is pretty much the same thing as their tutorial.

Second step: start sending logs

Now that we have an account, we can finally start sending logs. Make sure you are logged in your account for the next steps. I divided this section in two, one for Windows and one for Linux (I use Ubuntu).

Once logged in, click on “Send Your Data” in the top navigation: 

The next steps are starting to get interesting. We’ll configure the log shipper agents on Windows and Ubuntu.

Windows

On the left navigation, close “Log Shippers” that should be opened, and open “Operating Systems”:

Select “Windows” under the “Operating Systems” menu. Your page will refresh to the URL 

https://app.logz.io/#/dashboard/data-sources/Windows

They propose 2 options; we are interested in the option 1: Winlogbeat.

As they explain in the page, you first need to install Winlogbeat. So that’s what we’ll do.

Head over to https://www.elastic.co/downloads/beats/winlogbeat-oss and download the right MSI version for your computer (32 bits or 64 bits, if unsure use the 32 bits). For me, that’s the 64 bits MSI:

Note: here, my link is slightly different than the one they propose on their website. This is because I recommend using the OpenSource version (oss).

When the download is finished, click the downloaded file, a window will open.

Check the “I accept the terms in the License Agreement” checkbox and click “Install”:

When prompted, accept to run as Administrator (UAC). When the installation is done, click Finish (we leave the checkbox “Open winlogbeat data directory in Windows Explorer” checked.

In the Windows Exporer window that opened at the location “C:\ProgramData\Elastic\Beats\winlogbeat”, rename the file “winlogbeat.example.yml” to “winlogbeat.yml”.

Open your favorite text editor (it can be Notepad, I use VSCode) as Administrator (right click, Run As Administrator) and then open the file “winlogbeat.yml”.

Replace all the content of the file with the content from this gist:

In this content, you’ll find the text “YOURTOKEN_PLACEHOLDER”; replace this with the token they provide in the Logz.io settings page in the section “Account settings”:

Becareful, this token is secret! If someone get his/her hand on this token, they can send fake data to your account and overload it with garbage data.

Now, download the Logz.io public certificate and place it in “C:\ProgramData\Winlogbeat\COMODORSADomainValidationSecureServerCA.crt“. This certificate is available at https://raw.githubusercontent.com/logzio/public-certificates/master/AAACertificateServices.crt. You’ll need to do this using your text editor as Administrator.

When this is done, run the following command in a PowerShell window as Administrator: Restart-Service winlogbeat

That’s it, you should now receive your Windows logs in Logz.io! Head over to “Kibana” to see them come in (click “Refresh” if you don’t see them right away).

Note: You might have noticed that in the winlogbeat.yml I enabled logging of Sysmon. I plan to make a blog post to explain what is Sysmon and how to use it. For the moment, it doesn’t mather if Sysmon is not installed, Winlogbeat will simply ignore this config line.

Hint: You can enable the Dark Theme for Kibana in the Logz.io settings page

Ubuntu

Note: There is a TL;DR; section at the end. For this section, I assume you know how to use the Command Line Interface (CLI). For Ubuntu, we will be using Filebeat. By default, if you send logs using rsyslog, the data will not be encrypted over the internet, which is not recomended. By using filebeat, we can send encrypted data easily. On the left navigation, in “Log Shippers” that should be opened (if not, open it), click on “Filebeat”. As they explain in the page, you first need to install Filebeat. So that’s what we’ll do. Run the following commands: Note: here, my link is slightly different than the one they propose on their website. This is because I recommend using the OpenSource version (oss).

curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-oss-7.10.0-amd64.deb
sudo dpkg -i filebeat-oss-7.10.0-amd64.deb
rm filebeat-oss-7.10.0-amd64.deb

We also need the Logz.io public certificate. Run the following command:

sudo curl https://raw.githubusercontent.com/logzio/public-certificates/master/AAACertificateServices.crt --create-dirs -o /etc/pki/tls/certs/COMODORSADomainValidationSecureServerCA.crt

Next, we’ll configure filebeat to ship the logs to Logz.io using my default template and some bash-foo. When asked for the token, provide the token available in the Logz.io settings page in the section “Account settings”:

Becareful, this token is secret! If someone get his/her hand on this token, they can send fake data to your account and overload it with garbage data.

Run the following commands:

sudo curl https://gist.githubusercontent.com/tristandostaler/7a212a0ba23b97c97a5e2c6925bde240/raw/72c90076cf4aa16179c123316b3ef8cec775d576/filebeat.yml --create-dirs -o /etc/filebeat/filebeat.yml
echo -n "Please enter your logz.io Token: " && read -s LOGZ_TOKEN && sudo sed -i "s|YOURTOKEN_PLACEHOLDER|$LOGZ_TOKEN|g" /etc/filebeat/filebeat.yml

Now we only need to start FIlebeat and the logs will start shipping! Run the following command:

sudo systemctl start filebeat || sudo service filebeat start
(sudo systemctl enable filebeat) || (sudo update-rc.d filebeat defaults && sudo update-rc.d filebeat enable)

That’s it, you should now receive your Ubuntu logs in Logz.io! Head over to “Kibana” to see them come in (click “Refresh” if you don’t see them right away).

Note: You might have noticed that in the filebeat.yml I enabled logging of many systems that are not installed by default, like auditd. I plan to make a blog post to explain what is auditd and how to use it. For the moment, it doesn’t mather if auditd is not installed, filebeat will simply ignore this config line.

Hint: You can enable the Dark Theme for Kibana in the Logz.io settings page

TL;DR; putting all the commands together:

curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-oss-7.10.0-amd64.deb
sudo dpkg -i filebeat-oss-7.10.0-amd64.deb
rm filebeat-oss-7.10.0-amd64.deb
sudo curl https://raw.githubusercontent.com/logzio/public-certificates/master/AAACertificateServices.crt --create-dirs -o /etc/pki/tls/certs/COMODORSADomainValidationSecureServerCA.crt
sudo curl https://gist.githubusercontent.com/tristandostaler/7a212a0ba23b97c97a5e2c6925bde240/raw/72c90076cf4aa16179c123316b3ef8cec775d576/filebeat.yml --create-dirs -o /etc/filebeat/filebeat.yml
echo -n "Please enter your logz.io Token: " && read -s LOGZ_TOKEN && sudo sed -i "s|YOURTOKEN_PLACEHOLDER|$LOGZ_TOKEN|g" /etc/filebeat/filebeat.yml
sudo systemctl start filebeat || sudo service filebeat start
(sudo systemctl enable filebeat) || (sudo update-rc.d filebeat defaults && sudo update-rc.d filebeat enable)

Conclusion

That’s it, you now have your initial setup for a SIEM, with logs being sent! Of course, at the moment there are no alerts and the platform we are using don’t offer all the features we would like from a SIEM. But this is perfect to start learning to use a SIEM! In the next blog post SIEM 101 — Basic usage, I explain the basic usage of Logz.io, how to search logs, how to create an alert, etc.

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/

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.

Note: Sysmon is needed to detect this behavior. You can read my post SIEM 201 — What is Sysmon on the subject.

The 3 events are:

1. An incoming connection is made on the port 445 or 135 (Sysmon event ID 3 AND destination port: 445 OR 135)

2. An executable file is created in C:\Windows\ (Sysmon event ID 11 AND target filename: C:\Windows\[^\]+\.exe)

3. The executable from the step 2 is executed (Sysmon event ID 1 AND image: C:\Windows\[^\]+\.exe. The image should be the same as the target filename of the step 2)

The result should have no false positive (it would detect the normal usage of PsExec, so make sure to whitelist your allowed users).

In a Lucene query format, it should give something like this (adapt the field names to your context):

(event.code: 3 AND winlog.event_data.DestinationPort: (135 OR 445)) OR (event.code: 11 AND winlog.event_data.TargetFilename: /C:\\Windows\\[^\\]+\.exe/) OR (event.code: 1 AND winlog.event_data.Image: /C:\\Windows\\[^\\]+\.exe/)

Then, you can correlate the winlog.event_data.Image with the winlog.event_data.TargetFilename, but with a simple hack that don’t give a lot of false positive, that’s not necessary: you can simply make sure that the number of unique event.code in your results is equal to 3. This is what I’ll be doing. Head over to Logz.io and login to your account.

The same logic can be applied to detect SCShell, WMIExec and SMBExec, but the detection details are a bit different; I might write another blog for these ones.

In practice

The first thing to do is to simulate a remote PsExec execution so we can detect it. First download and extract PsExec which is bundled with a few tools called the PsTools: https://download.sysinternals.com/files/PSTools.zip

In the location of the extraction, open PowerShell as Administrator (File -> Open Windows PowerShell -> Open Windows PowerShell as administrator). For me the working directory of PowerShell is “C:\Users\User\Downloads\PSTools”. Then execute the following command:

(Get-NetIPAddress).IPAddress | Where-Object {($_ -ne "127.0.0.1") -and ($_ -ne "::1") -and ($_ -notlike "*:*")} | %{.\PsExec.exe \\$_ cmd}

After running this command, you will be in a cmd.exe context. You can simply write “exit” to go back to PowerShell. At this point you generated a remote PsExec execution, we now need to find it in the logs.

Now in Kibana search the query (it’s the same as above):

(event.code: 3 AND winlog.event_data.DestinationPort: (135 OR 445)) OR (event.code: 11 AND winlog.event_data.TargetFilename: /C:\\Windows\\[^\\]+\.exe/) OR (event.code: 1 AND winlog.event_data.Image: /C:\\Windows\\[^\\]+\.exe/)

We can see that we get the pattern I described above:

Now click on Create alert.

I recommend using a Group by on “beat_agent.hostname” because if you have more than 1 computer or server, the event could get mixed between computers and you could get a lot of false positives.

Now, to use the small hack I described above, so we don’t have to correlate events, in the “Trigger if…” section, check that the unique count of event.code is equal to 3. That way, the alert will trigger if and only if the 3 events are met in a small period of time:

We need this little hack because on Logz.io we can only do 2 step correlations and we would need 3 steps for this specific detection case. There are other platforms that allow to correlate more events, so you could do the correlation logic, but there are also some platform that don’t allow correlation so this hack could come in handy.

Conclusion

That’s it, you can now detect when a hacker uses PsExec to move laterally. Of course, you might need to whitelist some source IP or source IP range if you use PsExec legitimately in your context to allow known Administrators VLAN to use it.

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/

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

As I explained, this use case is really really simple. We’ll send an email if the event for a failed logon is triggered at least 5 times in a 5 minutes period. The Event ID for a failed logon in Windows is 4625 so the query is pretty simple: event.code: 4625. When creating the alert, we simply need to Group by beat_agent.hostname and winlog.event_data.TargetUserName and check if the number of logs in the last 5 minutes is ≥ than 5.

The group by beat_agent.hostname is necessary because if we have more than 1 Windows in our SIEM, as soon as 5 computers or less do 5 failed logon in the same 5 minutes block, the alert would trigger, and this is not a bruteforce and happens pretty often. The group by winlog.event_data.TargetUserName is necessary if you have some user that connects from time to time to different machines. If you were to not group by winlog.event_data.TargetUserName, you would detect a password spray attack which is an interesting Use Case but it’s not the purpose of this post.

For the sensitivity (5 failed logon in 5 minutes), I’ll explain how we can tweak it and reduce the false positive later in this post.

For the next part, head over to Logz.io and login to your account.

In practice

The first thing to do is simulate a bruteforce.

If you don’t have winrm enable on your computer, like it was the case for my test machine, open a PowerShell window as Administrator, and enter the following command:

Enable-PSRemoting -SkipNetworkProfileCheck -Force
Set-Item wsman:\localhost\Client\TrustedHosts -Value * -Force
Restart-Service WinRM

Next, enter this command to generate 5 failed logon on your computer:

[pscredential]$credObject = New-Object System.Management.Automation.PSCredential ("Non existent", (ConvertTo-SecureString "Bad password" -AsPlainText -Force))
for ($i=0; $i -lt 5; $i++) { Enter-PSSession -ComputerName localhost -Credential $credObject }

Now in Kibana, search the query:

event.code: 4625

You can add the following fields as columns: winlog.event_data.TargetUserName and beat_agent.hostname. You will get something similar to this:

Now click on Create alert and enter the alert name “Windows bruteforce”.

In the Group by field, add winlog.event_data.TargetUserName and beat_agent.hostname.

In the “Trigger if” section, change the values to match the following image:

In the Notify section, add your email and then save your new alert.

Managing false positives

When we first create this alert, the level of false positive we’ll receive is directly proportional to the size of the environment. The more Windows machines we have linked to the SIEM (inherently linked to the number of users) , the more likely false positives will arise.

There are a few strategies we can use to reduce the level of false positives:

1. We can reduce the sensitivity. Increase the threshold by reducing the time frame we look at, or increase the number of failed attempt.

2. Exclude some users from this specific alert and create a new alert less sensitive for these users.

3. Look only at bruteforce over RDP (query: “winlog.event_data.LogonType: 10”). And/or only at bruteforce over the nerwork (like in this example) (query: “winlog.event_data.LogonType: 3”). By doing this, we won’t alert when someone fails to enter his password on his own computer, which is the most frequent case of false positive we would get.

4. Whatever fits your environment. When creating an alert, it’s important to be creative and understand the usage patterns in our environments to reduce the level of false positive.

Note: you can see the logon types here: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4624

Edit: since I originally wrote this post, I found better ways to minimize False Positives. I summed them up in this post: https://www.tristandostaler.com/siem-103-detect-windows-bruteforce-part-2/

Conclusion

That’s it, you can now detect a Windows bruteforce and know how to manage false positives!

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/

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.

Sysmon can be used to detect suspicious and malicious events that would normaly not be visible in the default Windows logs. You can see all it can do and it’s corresponding event IDs here: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx?i=j and select Sysmon from the list.  

Installation

Note: There is a TL;DR; section at the end of this section. 

First download Sysmon here: https://download.sysinternals.com/files/Sysmon.zip Once downloaded, extract the content. In the Explorer window that opened after the extraction, open a PowerShell window as Administrator (FIle -> Open Windows PowerShell -> Open Windows PowerShell as administrator). For me, the working directory is “C:\Users\User\Downloads\Sysmon”. Next, we’ll use a config file that reduces the noise sent to the SIEM and that adds some useful logs not enabled by default. The detail of the config file we’ll use can be found at https://github.com/SwiftOnSecurity/sysmon-config. In the PowerShell window opened as Administrator, run the command:

Invoke-WebRequest -URI https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile sysmonconfig-export.xml

Now we simply need to install Sysmon giving it this config file. Always in the PowerShell window opened as Administrator, run the command:

./sysmon.exe -accepteula -i .\sysmonconfig-export.xml

If you already had Sysmon installed, you can update the configuration with the following command:

./sysmon.exe -c .\sysmonconfig-export.xml

Now that we installed Sysmon, if you didn’t have it installed before, we need to restart Winlogbeat so it now sends the logs from Sysmon. Always in the PowerShell window opened as Administrator, run the following command:

Restart-Service winlogbeat

That’s it, you should now be receiving the Sysmon logs.

TL;DR;

Putting all the commands together for easy installation, in a PowerShell window as Administrator, run the following commands:

cd C:\Windows\Temp\
Invoke-WebRequest -URI https://download.sysinternals.com/files/Sysmon.zip -OutFile Sysmon.zip
Expand-Archive .\Sysmon.zip
cd .\Sysmon\
Invoke-WebRequest -URI https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml -OutFile sysmonconfig-export.xml
./sysmon.exe -accepteula -i .\sysmonconfig-export.xml
./sysmon.exe -c .\sysmonconfig-export.xml
Restart-Service winlogbeat

How it can be used

The number of detection patterns that Sysmon allows are to numerous to talk about in one post, so I’ll only do a quick summary. I’ll use this site as a reference (select “Sysmon” once on the page): ultimatewindowssecurity.com 

Sysmon can log every process creation that happens in Windows. The processes that actually get logged depends on the config file we gave. With the config we gave in this post, we only exclude some known noisy processes so most of the activity we do can be logged. The event ID for a process creation is 1, as we can see in the ultimatewindowssecurity.com website. So if we go in our Logz.io account and search for “event.code: 1” (without the quotes), we can see all the process creation logs:

In this picture, I added relevant fields in the columns, here is what they mean:

• winlog.event_data.Image: This is the name of the process created

• winlog.event_data.CommandLine: This is the command line that was used when creating the process

• winlog.event_data.ParentImage: This is the Parent process; the process that created the current process creation log

• winlog.event_data.User: This is the user that created the process

If we look at all the available fields, we can see some interesting one:

• winlog.event_data.Hash.MD5: This is the MD5 of the current process that was created. This is useful to compare against a list of known malicious MD5. For example, we can look at this file tested in Virus Total: https://www.virustotal.com/gui/file/fb55414848281f804858ce188c3dc659d129e283bd62d58d34f6e6f568feab37/details. The process here is mimikatz, which is a really popular tool used by hackers. It’s MD5 is “2c527d980eb30daa789492283f9bf69e”, so if we were to see this hash in a process creation log, we would know it’s this specific mimikatz process.

• winlog.event_data.Hash.SHA256: This is the same as the MD5, but instead of a MD5, it uses SHA256 to hash the process. It can be used the same way.

• winlog.event_data.Hash.IMPHASH: This is similar to the last 2 fields, but a bit different. This is more advance so I won’t get in the details, but if you’re curious, there is a good article here: https://medium.com/@malcomvetter/defeating-imphash-fb7cf0183ac

Hint: Remember the website virustotal.com, it’s really useful! I might write a blog about it one day, but there is plenty of information online if you want to know more.Note: A process hash can be changed really easily, so don’t rely solely on these to detect bad behavior. Although they can be really useful for basics attacks, they are not perfect. 

So at this point, we could create an alert to detect specific process name or parent process name, or look at the hashes of the process that was created. For example, you could alert when you detect the creation of PsExec by looking at the process name, or when PsExec is used with a specific utility (like PowerShell), etc.

Conclusion

Sysmon is one of the best tool for a Blue Teamer. It’s usage will come back a lot. Altough it can’t do everything, it’s one of the best tool in your toolset. In my next blog posts, I’ll often reference to it. I suggest you read more on Sysmon and the patterns you can detect with it. You can also read on it’s configuration file format; I gave you a decent but basic configuration file and it could be enhanced and adapted to your context.

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 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.

Now that we receive our logs in our Logz.io account, it’s time to learn how we can navigate the logs, how they are organized and how to search for specific patterns. Once we know how to search patterns, we’ll be able to start creating alerts on specific pattern, like SSH bruteforce or Windows bruteforce.

The technology used by this SIEM

Let’s start with the technology. Logz.io is based on Elasticsearch as a database and uses Kibana to interact and visualize the data in the database. They added some custom features around these two tools to provide alerting and other things.

Elasticsearch – an ideal SIEM database

Elasticsearch is a “NoSQL” database that stores, indexes and provides analytics tools for JSON formatted data. The official description is:

Elasticsearch is a distributed, open source search and analytics engine for all types of data, including textual, numerical, geospatial, structured, and unstructured. Elasticsearch is built on Apache Lucene and was first released in 2010 by Elasticsearch N.V. (now known as Elastic). Known for its simple REST APIs, distributed nature, speed, and scalability, Elasticsearch is the central component of the Elastic Stack, a set of open source tools for data ingestion, enrichment, storage, analysis, and visualization. Commonly referred to as the ELK Stack (after Elasticsearch, Logstash, and Kibana), the Elastic Stack now includes a rich collection of lightweight shipping agents known as Beats for sending data to Elasticsearch.

Source: https://www.elastic.co/what-is/elasticsearch

Kibana – a basic SIEM interface

Kibana is a web-based user interface to visualize the data stored in Elasticsearch. It was designed by the same team that developed Elasticsearch and built specifically to interact with it’s data. The official description is:

Kibana is an open source frontend application that sits on top of the Elastic Stack, providing search and data visualization capabilities for data indexed in Elasticsearch. Commonly known as the charting tool for the Elastic Stack (previously referred to as the ELK Stack after Elasticsearch, Logstash, and Kibana), Kibana also acts as the user interface for monitoring, managing, and securing an Elastic Stack cluster — as well as the centralized hub for built-in solutions developed on the Elastic Stack. Developed in 2013 from within the Elasticsearch community, Kibana has grown to become the window into the Elastic Stack itself, offering a portal for users and companies.

Source: https://www.elastic.co/what-is/kibana

The interface

For the next steps, login in your Logz.io account and head over to Kibana:

As you can see, there are a lot of information available in a compact manner.

The top section, like in the picture below, allows to navigate in the available Logz.io features / sections

We’ll talk about each of them in details when the time comes, but in a few words:

• Metrics is used to have an easy and centralized view of your server(s) metrics, like CPU usage, memory usage, etc.

• Live Tail is used to look at the logs as they come in the platform, in real-time.

• Send Your Data is where you can get details on how to connect many platforms and technologies to Logz.io.

• Alerts & Events is where we go to create and modify alerts.

• Insights provide useful hints on what problems might be occurring in your server(s).

• ELK Apps is a marketplace of Dashboard, Alerts and other useful tools provided by Logz.io and the community.

For the left section, you can press the button to the bottom to expand the section:

Once expanded you get the following :

The Discover section is the one you see as you come on the site. It allows to search and browse the data. We’ll have a look later in this post.

The Visualize section is used to generate aggregated graphs (Pie Chart, Data Table, Heat Map, Region Map, Line Graph, etc.). This is really useful to easily make sense of a lot of data. For example, you could search for the most common processes started on a single server or on all your servers. Or you could draw the total traffic logs over time for your website to better understand your peak hours.

The Dashboard is useful to create, you guess it, dashboards. They are a centralization of multiple saved Visualize graphs. They allow to quickly see different pattern that interest us in a centralized place. Also, any filter you apply on the dashboard will be applied to all the Visualization in the dashboard. For example, if you have a dashboard for your website traffic, you can isolate a single IP and see all the Visualization graphs automatically updated to display info on that single IP.

Timelion is useful to overlay and compare different time-based graphs. You could, for example, compare the traffic between 2 servers by having them in a single graph.

The Management section is for, well, management (of Kibana). But this is for advanced users and we don’t have to go there often, so I won’t go in details.

In the top of the center section we have the search tools:

Here we can use a Lucene query or a Kibana Query Language (KQL) query to search for the data. We can also apply filters (for example: “IP: 127.0.0.1”).

On the right we have the time period over which we apply our search (in the picture here the data displayed is from the 15 minutes before the moment the search was launched).

To refresh the data, we can press the “Refresh” button. It is possible to Save a search so they can be Opened at another time, or Shared.

The big “Create alert” button is useful to quickly jump to the section to create an alert from the currently applied query and filters. This is what we’ll be using later to create an alert.

In the left of the center section we have all the fields available from our logs. We can interact with these fields (filter, visualize, etc.):

The Selected fields are the one used as columns in the main center section. When you hover on a field, the “add” button appears. You can add columns to the main center section by clicking on the “add” button. You can also click a field to get a quick view of the top values for that field.

Note: If you get the button “Field not indexed”, simply click on it. The page will refresh and the field will be available.

In the center of the center section we have the main section:

At the top of the main section we have a timeline for the count of messages over a period or time.

In my picture, we can see I have around 3 messages per period of 20 seconds, for a total of 68 messages (hits). You can use your mouse to select a time period and change your time frame (here being the “Last 15 minutes”).

Note: in my blog, “messages” and “logs” are interchangeable and are used to describe a single event that happened on the server or computer, like a logon.

Then we have the logs. This is where all the magic happens:

Here I only have 2 columns selected: Time and message. If you where to add more fields as column, they would be visible here.

When you hover on a field (like “message”) you get an X to remove the field from the displayed columns.

If you click on the small arrow to the left of the row, you can expand the specific log to see all the fields and their values:

Here, on the left is the name of the field, like “@metadata.beat” and on the right is the value, like “winlogbeat”. If you hover on the field, you get 4 icons:

The + and – are used to add a filter to specifically search for the value or to remove the value from the results, respectively. The next icon to the right is used to add the field as a column and the last one is to add a filter to make sure the field is present in the log (for example, exclude the logs that don’t have an IP).

Navigating the logs in a SIEM

To learn how to navigate the logs, we’ll use a useful context in windows environment: we’ll search for the last user that logged in.

A quick google for “windows view the logon events” give me many results, including https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/basic-audit-logon-events.

By reading we can understand that Windows logs the logon events. By scrolling a little, we can see the “Logon events” number and their matching description. Here “4624” looks like what we are looking for: “A user successfully logged on to a computer.”.

Hint: learn the event IDs 4624 and 4625, they are used really often in a Windows environment!

So back in Logz, we need to find the field that contains the 4624. What happens if I search for “4624”?

No results… Hum… Ohhh the time frame! I didn’t login in the last 15 minutes. Let’s change that to 60 minutes ago and click the Update button.

14 hits! But wait, I didn’t login 14 times in the last hour? And what are these users with a dollar “$” sign I can see in the “message” column? Let’s ask Google. A search for “windows event id 4624 user with dollar sign”, first result: https://www.ultimatewindowssecurity.com/securitylog/book/page.aspx?spid=chapter5

Hint: you can save this site for later, ultimatewindowssecurity.com is filled with info on Windows event details, including Sysmon!

This page has a lot of info. Let’s jump to the explanation of the “$” sign with CTRL+F (search in page). We get this description:

DC Security logs contain many Logon/Logoff events that are generated by computer accounts as opposed to user accounts. As with computer-generated account logon events, you can recognize these logon and logoff events because the Account Name field in the New Logon section will list a computer name followed by a dollar sign ($). You can ignore computer-generated Logon/Logoff events.

So the events with these accounts are computer-generated Logon events. But they happen on a Domain Controller (DC). In my case, I am testing on a Windows instance not joined to a domain so this is not what I am looking for.

Let’s keep digging. The name of the field was “winlog.event_data.SubjectUserName”, I wonder if another field contains “UserName”. Looks like it: “winlog.event_data.TargetUserName”.

Hint: When DC joined, when you have more than one DC sending logs, you’ll get more than one user. You can enter the following query to filter our all the users with a dollar sign: “winlog.event_data.SubjectUserName: /.?$.?/” (without the quotes), the total query at this point being: “4624 AND NOT winlog.event_data.SubjectUserName: /.?$.?/” (without the quotes)

For simplicity, I’ll add the field “winlog.event_data.TargetUserName” as a column:

There you go, I now have useful details!

So it looks like my most recent logon was on “Nov 26, 2020 @ 21:13:04.405”.

Note: You might have noticed that the logs timestamp change from picture to picture, this is because as I write this post I update and refine my search so I can get useful images.

Creating an Alert – the best feature of a SIEM

Now we know how to search the logs, the only thing left is to create an alert and send an email. I’ll use the same context and create an Alert to email me every time I logon.

Note: this is used as an example only. If you create an alert like this, you’ll receive a lot of emails!

So, starting from my research for the most recent logon for my user named “User” (I know, it’s original!), I’ll add a filter specifically for my user so I don’t receive an email every time my computer generates an event:


We are now filtering specifically for the user “User”, but I don’t like the “4624” in the search bar, without specifying it’s field name; it’s comparing the value to all the values of all the fields! Now that we know we only have the real logon events for my user, let’s find the field name for the event ID 4624 with a CTRL+F “4624”:

Note: don’t forget to open a log so we can see all it’s field

Note: Kibana display the thousands with a comma so we need to search for “4,624”… I am Canadian, I hate this format 

Let’s filter for the value “4624” for the field “event.code” and remove the “4624” from the search bar and click the “Update” button:

Hint: For performance reasons, it’s better to use filters than the search bar, but that only work for exact matches.

Now that we have exactly the results we want, we know our query is good. Let’s click the big blue “Create alert” button. We are redirected to the “Alerts & Events” section of Logz.io.

We give the alert a name: “The user User logged on”

Leave everything as is, up to the section “Notify” (the query in the section “Search for…” is pre-filled with the filters we prepared before, thanks to the big blue button).

You can give a useful description if you want, I don’t as my alert title is clear enough.

Then in the field “Who to send it to”, simply write your email and select it.

When you’re satisfied with everything, click the “Save” button on the top right:

The only thing left is to test the alert. Simply login on your computer and you should receive an email in the next 15 minutes (that’s the time I defined in the “Trigger if…” section). You will now receive an alert every time you login on your computer!

Note: If you add more computers, because we didn’t filter for the source, you would get an alert every time the user “User” logon on any computer.

Conclusion

That’s it! You now know the basics of Logz.io, how to search logs and how to create alerts, which is the basis of using a SIEM. I will leave to you the pleasure of discovering how to create Visualize graphs and Dashboards. There are a lot more things to learn, which we’ll do in time. Everything is now in place for me to start writing blogs on detection patterns! I’ll do simple patterns in the “SIEM 102” series, and more complex detection patterns in the “SIEM 201” series. I’ll eventually talk about how we can automate responses and transform and bonify the data.

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!

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!

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.

For this post, I assume you have WordPress installed on linux using Apache and that you are sending Apache’s logs, as defined in the filebeat configuration I provided in the “Initial Setup” post.
(Hint: LAMP)

Some background

To understand the next section, we need to understand how WordPress works when someone tries to login and how we can see this in the logs.

There are two ways to login to wordpress:

1. Through the standard login page (wp-login.php)

2. Through xmlrpc when not disabled

After a successful logon, we get redirected (302 Found) to the WordPress dashboard. When a failed logon occures, the response is different (we get a 200 OK and the page contains an error message).

The detection pattern

Now that we know how WordPress behaves when logging in, we know what to look for to detect a bruteforce attack.

The idea is to count the number of times the same IP sent a request to one of the login pages and got something else than a successful logon response. When the count reaches a defined threshold (like 10) in a defined time window (like 5 minutes), we consider it as being a bruteforce attack. In our case, we’ll simply send an email, but we could automatically block the attacking IP.

Here are the useful elements:

The query: request: (/.*wp-login.*/ OR /.*xmlrpc.*/) AND NOT response: 302
The field “request” is the field, after parsing, that stores the page being accessed. The field “response” is the field, after parsing, that stores the response code of the request.

First group by: beat_agent.hostname
This group by is necessary if we plan, or do, have more than 1 WordPress website, or any website with these login pages.

Second group by: geoip.ip
(or simply “ip”, depending on your config)

This group by is necessary because we want to know what IP is attacking us so we can eventually take an action. This info could also be usefull in an investigation.

For the sensitivity (10 failed login in 5 minutes), I find it to be sensitive enough for most attacks and it has a low level of false positives. But you can always tweak it to fit your context.

For those of you who tells me that “an attacker could make 9 attemps every 5 minutes to bypass your measure”, that is true, but a bruteforce attacks that does 9 attemps every 5 minutes will probably never succeed and the attacker will go elsewhere, to a more juicy target.

For the next part, head over to Logz.io and login to your account.

In practice

The first thing to do is simulate a bruteforce. Because we are only looking for 10 tries in 5 minutes, it’s feasible manually. If you had a more agressive threshold, you would need to develop a script to send login requests.

Head over to the login page of your WordPress website. For me that would be https://www.tristandostaler.com/wp-login.php.
Note: because I have some security plugins, this link is not normally working. I disabled the plugin while writing this post.

You can write anything in the fields Username and Password, then press “Log In”. Do this 10 times. You should now have 10 failed logon visible in the logs.

In Kibana, search the query: request: (/.wp-login./ OR /.xmlrpc./) AND NOT response: 302

You can add the following fields as columns: beat_agent.hostname, geoip.ip (or simply ip) and response (this one is not useful for the alert but we’ll add it to see the behavior I described). You will get something similar to this:

Here, we can notice a few things:

1. My hostname is “novutech.ca” and not “tristandostaler.com”. This is because I am hosting my site on the same server as the website I use to advertise my hosting services (the website needs to be updated, I know!)

2. The responses are “200”. This is, as I explained, the behavior that happens when a bad logon occurs.

3. We can see the IP 43.250.249.5 trying to bruteforce my site at the same time!

You can now click on Create alert and enter the alert name “WordPress bruteforce”.

In the Group by field, add geoip.ip (or ip) and beat_agent.hostname.

In the Trigger if section, change the values to match the following image:

In the Notify section, add your email and then save your new alert.

Managing false positives

After creating the alert, the number of false positive should be pretty low. But if you happen to get too much false positives in your environment, there are a few strategies we can use to reduce the level of false positives:

1. We can reduce the sensitivity. Increase the threshold by reducing the time frame we look at, or increase the number of failed attempt. A smaller timeframe will detect aggressive bruteforce but can be bypassed more easily. A higher number of failed attempts will increase the risk that an attacker guesses the right username / password combination before being locked out.

2. If you do have geoip enabled, you can have more sensitive alerts for some countries and less sensitive alerts for other countries.

3. Whatever fits your environment. When creating an alert, it’s important to be creative and understand the usage patterns in our environments to reduce the level of false positive.

Conclusion

That’s it, you can now detect a WordPress bruteforce and know how to manage false positives!

Don’t hesitate to write to me if you have any questions. This could also help me better understand how to write a good blog that answers most questions.

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!

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

Some background

Some background are required to understand his response.

First, it is important to know that Guillaume is an excellent attacker / hacker (Red Team). He works at the same company as me (Okiok) on the offense side. He is hired by companies, through Okiok, to test their defenses. It’s his job to know the best attacking tools available. His job is to simulate an attack by a highly skilled bad actor.

Second, Fireprox is a tool that uses some features of Amazon Web Services (AWS) to send requests from AWS’s IPs. AWS is a cloud provider; they offer many cloud services like storage, computing, etc. They own a huge amount of IP addresses so Fireprox leverages this feature to send requests to website using a new IP on almost every request (with some limitations).

In my post, I explain that we can detect a simple bruteforce if the same IP does 10 tries in 5 minutes. Because Fireprox uses a different IP (almost) every request, it can bypass this detection pattern.

My answer: a good InfoSec Strategy

The short answer is: you need a good InfoSec Strategy. There are a few key elements to answer this comment:

1. A SIEM, and any detection use cases, is not a silver bullet. One use case is designed to detect one pattern of attack, but there are always new attacks. A SIEM is something that keeps evolving. It’s important to add new detection use cases as needed, and remove the old ones that are out of date.

2. A defense in depth approach is key. It’s important to have many layers of security measures.

3. Understand your Threat Model. The idea is to understand who might target you, from an unskilled bad actor to an APT.

The lifecycle of a Use Case

When using a SIEM, we’ll develop more and more detection use cases as we learn of new attacks, we introduce new software and systems, etc. The problem with this is that the more use cases we have, the more resources are needed to run and operate the SIEM, without counting the false positive rate and time to maintain them.

As we add people, devices, systems and software in our environment, the existing use cases might start to generate more and more false positives. Because of this, it’s important to revisit the existing use cases and evaluate what strategy can be used to reduce the level of false positives. To get some ideas on false positive mitigation strategies, you can review the following posts:

1. SIEM 102 — Detect WordPress bruteforce

2. SIEM 102 — Detect Windows bruteforce

3. Be creative! Try to find new ways to reduce the level of false positives without increasing the level of false negatives

As a use case ages, it might become obsolete if, for example, the technology we try to protect is not used anymore. For example, if I were to change from WordPress to another CMS for my blog, any use case base on WordPress would become obsolete, but they would continue to impact the SIEM’s performance and it’s maintenance. For this reason, it’s important to periodically revisit and question if the use case is still useful.

When I say it would impact maintenance, this is because when you have a lot of use cases, it clusters the view of the SIEM and/or reports and affects any statistics you have (ex: what’s the percentage of use cases that trigger every weeks)

A defense in depth strategy

I couldn’t presume to produce a better definition of what is Defense in Depth than the CIS:

Defense in Depth (DiD) refers to an information security approach in which a series of security mechanisms and controls are thoughtfully layered throughout a computer network to protect the confidentiality, integrity, and availability of the network and the data within. While no individual mitigation can stop all cyber threats, together they provide mitigations against a wide variety of threats while incorporating redundancy in the event one mechanism fails. When successful, this approach significantly bolsters network security against many attack vectors. An effective DiD strategy may include these (and other) security best practices, tools, and policies.

https://www.cisecurity.org/spotlight/cybersecurity-spotlight-defense-in-depth-did/

With an analogy, it’s like a car and it’s many defense mechanism to reduce injuries and deaths: Collision avoidance system, Anti-lock braking system, air bags, seatbelt, etc. Like with a car, it’s not completely risk proof. But the more layer you have, the less risk you have.

Using my WordPress server as an example, I have many layers to secure it as much as possible according to my Threat Model:
Note: this list is incomplete as I do not want this post to be too big, but it give a good idea of what I’ve done

1. WordPress and all the plugins are always up to date

2. I have a few security plugins, some of them provide bruteforce protection

3. I have MFA enabled for the login

4. The login page is unavailable (it is, but you need to know how. A little bit of security through obscurity can help sometime!)
   Note: this point changed since I did this post. I am now using another security plugin and other tools and I needed to keep the normal URL for the login page. But I added other mitigation strategies around the login page.

5. The web server logs are sent to my logz.io stack with a few detection use cases and automated actions to block attacking IPs

6. My server has fail2ban

7. My server provider offers some basic protection, like DDOS.

8. I have write-only backups (you need special access to read and restore)

9. Etc.

Understand your Threat Model

A Threat Model analysis is where you carefully analyze what are your attack vectors, what bad actors might be interested in your assets and to which ones. There are many ways to analyze this and I will dedicate a post for this at some point.

I didn’t do a complete and thorough Threat Model analysis for my blog, but I am basing mine on my gut feeling and my experience (if you are doing this for an enterprise, don’t! You are way more interesting to bad actors than me!).

In my case, I don’t have much asset of value and I have backups in case of a ransomware or a DOS of some kind (like if I do an error in a config). The most important thing I try to protect is my time because restoring a backups or something like that is time consuming. From the bad actors point of view, my server could also be useful in a botnet. Since I started publicizing my blog, I know some script kiddies might try to hack my website in some way, including with a DDOS.

Based on this, I think that the protection layers I have are more than enough. If I look at the attacks I block almost everyday, I know I am protected against the most probable attacks on my server, including a distributed bruteforce, like my fiend was proposing.

Conclusion

Like I thought, it took me more than 280 characters to answer this question 😉
I know I touched some point I didn’t address yet in my blog, but I plan on talking in depth about most of them at some point. Don’t forget that the initial post name was “SIEM 102 (…)”. For the moment I am only talking about the base and I already have plans for some “SIEM 401” posts!

I am glad Guillaume asked me this question though, as this allowed me to see what subject I should address in the future. Thanks Guillaume!

Don’t hesitate to write to me, like Guillaume did, if you have any questions. This could also help me better understand how to write a good blog that answers most questions.

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!

This post is a follow up of the post SIEM 102 — Detect Windows bruteforce where I explained how to create a detection Use Case to detect a Windows bruteforce.

In this post I will explain how we can enhance the original detection logic by having a lower False Positive rate.

As I explained in the last section of the initial post, it is important to manage False Positives (FP). In the past few months, I spent some time to look for ways to reduce FP and this post will summarize them.

The context

We sometime received some alerts that we needed to investigate to understand what was happening. After the investigation, we found that it was sometime because someone mistyped their username, or it was a on a disabled account (through an automated script for example), etc. All these cases where not a bruteforce attack currently occurring on a user account.

We wanted to lower the amount of alerts we receive and only receive useful alerts.

We used 2 tactics to do so:

1. Have different Threshold based on the logon type

2. Adjust the query to only alert on relevant reasons

Threshold based on the logon type

If you look at what information an event for a bad logon has (event id 4625: ultimatewindowssecurity.com) you’ll notice it has a Logon Type. You can find the detail of what these Logon Type code means on the page ultimatewindowssecurity.com:

• 2: Interactive (logon at keyboard and screen of system)

• 3: Network (i.e. connection to shared folder on this computer from elsewhere on network)

• 4: Batch (i.e. scheduled task)

• 5: Service (Service startup)

• 7: Unlock (i.e. unnattended workstation with password protected screen saver)

• 8: NetworkCleartext (Logon with credentials sent in the clear text. Most often indicates a logon to IIS with “basic authentication”) See this article for more information.

• 9: NewCredentials such as with RunAs or mapping a network drive with alternate credentials. This logon type does not seem to show up in any events. If you want to track users attempting to logon with alternate credentials see 4648. MS says “A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.”

• 10: RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance)

• 11: CachedInteractive (logon with cached domain credentials such as when logging on to a laptop when away from the network)

A description for all the Logon Types. Source: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4624

Based on this, we created 2 different alerts with 2 different threshold:

1. If the connection is from the network and non-interactive (if the Logon Type is 3), we alert if there was 25 tentative for the same user from the same source. This greatly reduces the FP for cases like Windows trying to list shares (which happens a lot). We also reduced the severity for this case.

2. If the connection is of any other type (if the Logon Type is not 3), we alert if there was 5 tentative for the same user from the same source. The rule is “if the Logon Type is not 3” but in reality it ends up being often of either a type 2 or a type 10 meaning they are interactive. These kind of alerts do not occur often and are really reliable (even more so if we count in the tactic from the next section). We kept the original severity for this one.

Having these 2 different alerts is really useful to receive relevant alerts and knowing in one look if it’s interactive or not (we added a group by on the Logon Type so we have this information in the email we receive).

Alert only on relevant reasons

If you look at what information an event for a bad logon has (event id 4625: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4625) you’ll notice it has a Sub Status. This Sub Status gives a reason for the failed logon. You’ll notice that some of these reasons are not relevant to detect a bruteforce (for example, if the event is created for a user that does not exists, this is not a bruteforce (of course, we could create an alert to detect this specific Use Case)). However, this table is incomplete. The complete list can be found on Microsoft’s website: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625. Here is the table:

Status\Sub-Status - Code Description

0XC000005E - There are currently no logon servers available to service the logon request.

0xC0000064 - User logon with misspelled or bad user account

0xC000006A - User logon with misspelled or bad password

0XC000006D - The cause is either a bad username or authentication information

0XC000006E - Indicates a referenced user name and authentication information are valid, but some user account restriction has prevented successful authentication (such as time-of-day restrictions).

0xC000006F - User logon outside authorized hours

0xC0000070 - User logon from unauthorized workstation

0xC0000071 - User logon with expired password

0xC0000072 - User logon to account disabled by administrator

0XC00000DC - Indicates the Sam Server was in the wrong state to perform the desired operation.

0XC0000133 - Clocks between DC and other computer too far out of sync

0XC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine

0XC000018C - The logon request failed because the trust relationship between the primary domain and the trusted domain failed.

0XC0000192 - An attempt was made to logon, but the Netlogon service was not started.

0xC0000193 - User logon with expired account

0XC0000224 - User is required to change password at next logon

0XC0000225 - Evidently a bug in Windows and not a risk

0xC0000234 - User logon with account locked

0XC00002EE - Failure Reason: An Error occurred during Logon

0XC0000413 - Logon Failure: The machine you are logging on to is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.

So after analyzing all the Sub Statuses, we ended up removing all the ones we don’t care about in the context of a bruteforce detection. We ended up adding to the query: (…) and if the Sub Status is not one of:

("0XC000005E", "0XC000006E", "0xC000006F", "0xC0000070", "0xC0000071", "0xC0000072", "0XC00000DC", "0XC0000133", "0XC000015B", "0XC0000192", "0XC0000225", "0XC00002EE", "0x0", "0X80090325", "0xC0000064")

By removing all of these, we removed almost all FP and only detect true Windows bruteforce. For example, we received a total of 9 alerts in the last 90 days (at the time of writing these lines) and after verification, they were all cases where the person made an error (new employee, recently changed the password, etc.).

Conclusion

As you can see, any alert can be tweaked to have a really low level of False Positives while also staying relevant. We can use many tactics and only detect a true Windows bruteforce. The trick is to invest some time to analyze what information we have and think what tactics can be used to keep only relevant alerts.

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

Originally published at https://www.tristandostaler.com on June 4, 2022.

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!

Here are the posts I did using Logz.io for my examples:

• https://www.tristandostaler.com/siem-101-introduction/

• https://www.tristandostaler.com/siem-101-initial-setup/

• https://www.tristandostaler.com/siem-101-basic-usage/

• https://www.tristandostaler.com/siem-102-detect-windows-bruteforce/

• https://www.tristandostaler.com/siem-102-detect-wordpress-bruteforce/

• https://www.tristandostaler.com/siem-201-what-is-sysmon/

• https://www.tristandostaler.com/siem-202-detecting-remote-psexec/

The Reasons

There are 3 reasons why I switched:

1. The retention period for the free tier

2. The ease of use of the platform

3. It’s powerful features for advanced users

The Retention Period For The Free Tier

In Logz.io, the free version allows for 1 GB of log sent per day, and the logs are kept for 1 day. However, I have been using Logz.io for a long time so my account is using their previous free version which allowed for 3GB of log per day, for 3 days retentions.

Source: https://logz.io/pricing/

However, Humio, with their community version, allows to send up to 16GB of log per day, with a retention period of 7 days.

Source: https://www.humio.com/getting-started/community-edition/

Since I am using these platforms to test different strategies of using SIEMs, I need more than 3 GB per day, and ideally I need more than 3 days of retention, because sometimes I debug something a few days after a bug is detected (I have a fulltime job after all). So by having a lot more data I can send, and having this data retained for a longer period, Humio better fits my needs.

I do need more than 3 GB per days because I am sending logs from multiple machine, Windows, Linux and other devices like my router. Also, I am testing tools like the new Sysmon for Linux and to fully test it, I need to be able to send a lot of data by having a non-optimized configuration so that I can understand how to optimize the config. Another tool I am testing is Packbeat which send information about every connection made to a machine (there are configuration that can be done to reduce the noise).

The Ease Of Use Of The Platform

Humio is really easy to use. For basic use, it’s as easy as Logz.io. However, for some features like modifying how the data is parsed, in Logz.io it is a lot harder than in Humio. In Humio, customizing how the data is transformed before being saved in the database is a lot easier: you simply query for the data you want to transform (“*” for everything, I query by type so “type = syslog”) and then you can use powerful functions to modify the data. When you are satisfied, save the query and use it in the parser configuration.

Here is an overview of my config for Syslog:

It is important to note however that it took me some time to find the optimal way to configure the parsers. That would need a blog post of it’s own, but in a few words, the easiest way is to use saved queries as much as possible because it’s easier to modify. I only have 2 parsers, one for winlogbeat and one for filebeat. Filebeat is the most complex as it handles different types, but both of them use the saved query “Post Process”. This saved query itself uses 2 other saved queries: “Normalize” and “Enrich”. This way, I can modify the “Normalize” query, save it, and all my logs now have the new config.

The Powerful Features For Advanced Users

It is, in my opinion, extremely important that a SIEM is easy to use for beginners. Unless your in a multi-billion enterprise, I don’t think it should be required to hire an expert with 10 years experience in your specific SIEM technology to be able to use a SIEM and secure your enterprise.

But as much as I hold on tight to that principle, I think a SIEM should also allows for advanced users a way to be more efficient; an “expert mode”. For me, it’s OK if that expert mode is by using an API to update a config or an alert, but in Humio, we have the advantage to have this expert mode easily available and usable. The downside is that Humio is a little bit harder to use that Logz.io (or Kibana based SIEMs), so it’s definitely not a perfect solution. But I think they found an acceptable balance between ease of use and power user features for most companies.

Some of these features for Humio are:

1. The way we can modify parsing queries using already ingested logs to test against real data

2. The way we can create alerts (it’s almost the same as a saved query)

3. The way they designed alert throttling is really powerful

4. They support multiple type of actions for alerts (email, HTTP requests, etc.) and the configuration is easy to do

5. The query language support “Piped” queries

6. The documentation is complete and well done

7. It is relatively easy to segregate data and control who has access to what with which rights

8. Etc.

Conclusion

Although Humio is not a perfect solution and is missing some key SIEM features that some enterprise would look for, in my context it is more than enough and I am definitely using it as a SIEM.

The fact that we can send a lot of data also allows us to test the platform and other technologies. And the “expert mode” is definitely enjoyable to use, a lot more than many other platforms I have tried.

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