Showing posts with label SIEM. Show all posts
Showing posts with label SIEM. Show all posts

Splunk UseCase for attacks against FortiGate Firewall management interfaces

If you are using Splunk as your SIEM you can try to detect attacks against your FortiGate firewalls by using the following SPL query:


index=firewall type=event subtype=system msg IN ("Failed to match community*", "Message authentication or checking failed*", "Negotiation failed: no matching*", "Negotiation failed: Broken pipe*")
| stats earliest(_time) as FirstEvent count by devname,msg,result,logdesc
| eval FirstEvent=strftime(FirstEvent,"%Y-%m-%d %H:%M:%S")

Splunk UseCase FortiGate Firewall Management Interface Attacks


Additionally: It is imperative that you protect your FortiGate interfaces with TrustedHosts AND Local-In-Policies. Only using TrustHosts protects HTTPS, SSH, etc but not other protocols like SIP, IPsec, CAPWAP, BGP, OSPF, SSLVPN etc which are also local services running on the FortiGate, which need to be protected, too.
See https://how2itsec.blogspot.com/2022/10/fortigate-admin-interface.html

Cribl - Change values to lowerCase

Some logs (e.g. Microsoft Azure) sometimes are not fully normalized to all lowercase characters. You can use Cribl to adjust those values by either use the eval or mask function:


Eval

_raw.toLowerCase()

Cribl Eval _raw:toLowerCase

Cribl eval _raw:toLowerCase

https://docs.cribl.io/stream/eval-function/ 

"The Eval Function adds or removes fields from events. (In Splunk, these are index-time fields.)"


Mask

You can also use Cribls mask function to hit all fields:

Regex = (.*)        <---- 1st Capturing Group (.*), see https://regex101.com/


g1.toLowerCase

Cribl Mask g1.toLowerCase



https://docs.cribl.io/stream/mask-function/

"The Mask Function masks, or replaces, patterns in events. This is especially useful for redacting PII (personally identifiable information) and other sensitive data."



Filter logs in Splunk - example filtering monitor probe checks

When running Splunk you want to filter logs, for example to get rid of the many health check probe querys from your monitoring system.

Example filtering PRTG monitoring probe requests using props.conf and transforms.conf

1. Find the monitoring probes in the logs in splunk, e.g.:

10.148.227.111 - - [18/Jul/2024:23:21:06 +0200] "GET /login HTTP/1.1" 200 12882 "-" "Mozilla/5.0 (compatible; PRTG Network Monitor (www.paessler.com); Windows)"
10.148.227.111 - - [18/Jul/2024:23:21:06 +0200] "GET / HTTP/1.1" 302 5793 "-" "Mozilla/5.0 (compatible; PRTG Network Monitor (www.paessler.com); Windows)"
10.148.227.111 - - [18/Jul/2024:23:20:56 +0200] "GET /login HTTP/1.1" 200 12882 "-" "Mozilla/5.0 (compatible; PRTG Network Monitor (www.paessler.com); Windows)"
10.148.227.111 - - [18/Jul/2024:23:20:56 +0200] "GET / HTTP/1.1" 302 5790 "-" "Mozilla/5.0 (compatible; PRTG Network Monitor (www.paessler.com); Windows)"
10.148.227.121 - - [18/Jul/2024:23:12:17 +0200] "GET /login HTTP/1.1" 200 17480 "-" "Mozilla/5.0 (compatible; PaesslerCloudBot/1.0; https://www.paessler.com; 576bb8887fe66b1eece876e62e701b9e)"
10.148.227.121 - - [18/Jul/2024:23:12:16 +0200] "GET / HTTP/1.1" 302 5572 "-" Mozilla/5.0 (compatible; PaesslerCloudBot/1.0; https://www.paessler.com;
576bb8887fe66b1eece876e62e701b9e)"
10.148.227.121 - - [18/Jul/2024:23:12:15 +0200] "GET /login HTTP/1.1" 200 17486 "-" "Mozilla/5.0 (compatible; PaesslerCloudBot/1.0; https://www.paessler.com;
576bb8887fe66b1eece876e62e701b9e)"
10.148.227.121 - - [18/Jul/2024:23:12:15 +0200] "GET /login HTTP/1.1" 200 17474 "-" "Mozilla/5.0 (compatible; PaesslerCloudBot/1.0; https://www.paessler.com;
576bb8887fe66b1eece876e62e701b9e)"

2. Create a regex, which finds the logs (which a precise match but as less cpu steps as possible) using https://regex101.com/

regex101.com regex splunk filter

In this example the following regexes where used:

Mozilla\/\d+\.\d+\s+\(compatible;\s+PRTG\s+Network\s+Monitor
Mozilla\/\d.\d\s\(compatible\;\sPaesslerCloudBot\/\d.\d

 

3. Create a dedicated splunk app for this log source or use the default splunk search app and modify the props.conf. Create an entry which you map to the host, source or sourcetype and tell it to use transforms.conf:

uspunk@ubu2401spl:/opt/splunk/etc/apps/search/local#
uspunk@ubu2401spl:/opt/splunk/etc/apps/search/local# cat props.conf
[...]

#filter prtg monitoring logs
[host::fqdn.of.logsource]
TRANSFORMS-t1=filter-prtg-from-access
TRANSFORMS-t2=filter-prtgcloud-from-access

4. Modify the transforms.conf of this same splunk app. Create an entry which you map to the host, source or sourcetype and force it to the nullQueue:

uspunk@ubu2401spl:/opt/splunk/etc/apps/search/local#
uspunk@ubu2401spl:/opt/splunk/etc/apps/search/local# cat transforms.conf
#filter prtg logs von access.log von nextcloud
#
[filter-prtg-from-access]
REGEX = Mozilla\/\d.\d\s\(compatible\;\sPRTG\sNetwork\sMonitor
DEST_KEY = queue
FORMAT = nullQueue

[filter-prtgcloud-from-access]
REGEX = Mozilla\/\d.\d\s\(compatible\;\sPaesslerCloudBot\/\d.\d
DEST_KEY = queue
FORMAT = nullQueue

uspunk@ubu2401spl:/opt/splunk/etc/apps/search/local#

5. Reload the splunk configuration using https://your.splunk.fqdn:8000/en-GB/debug/refresh 

6. Your logs should be filtered. If not, check the btool to see if another splunk configuration takes precedence to your configuration:

./splunk btool props list
./splunk btool props list --debug
./splunk btool transforms list
./splunk btool transforms list --debug

AKS Security - SIEM UseCase of Get Credentials

A SIEM usecase or forensic security alert for Azure Kubernetes Service AKS should be setup for az aks get-credentials as it reveals sensitive data of AKS.

Example for Azure Cloud Shell Bash:

azureksmoq [ ~ ]$
azureksmoq [ ~ ]$ az aks get-credentials --resource-group rgaks04app23 --name AKS04
Merged "AKS04" as current context in /home/azureksmoq/.kube/config
azureksmoq [ ~ ]$ 
azureksmoq [ ~ ]$
azureksmoq [ ~ ]$ cat /home/azureksmoq/.kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZ[...]RVJUSUZJQ0FURS0tLS0tCg==
    server: https://mykubernetescluster-dns-[...].hcp.eastus.azmk8s.io:443
  name: AKS04
contexts:
- context:
    cluster: AKS04
    user: clusterUser_rgaks04app23_AKS04
  name: AKS04
current-context: AKS04
kind: Config
preferences: {}
users:
- name: clusterUser_rgaks04app23_AKS04
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ[...]RS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJV[...]0VZLS0tLS0K
    token: bl0c8ko2[...]73m4ltf
azureksmoq [ ~ ]$ 
azureksmoq [ ~ ]$ 

This command can be helpful for developers or admins - but it is dual use as it reveals sensitive information. I recommend increasing your SIEM risk score or even make a use case with alerting.

Azure Documentation

Microsoft documentation for az aks get-credentials can be found here: https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-get-credentials or see here: https://azure.github.io/kubelogin/quick-start.html. See also https://learn.microsoft.com/en-us/azure/aks/control-kubeconfig-access

Get access credentials for a managed Kubernetes cluster.

By default, the credentials are merged into the .kube/config file so kubectl can use them. See -f parameter for details.

az aks get-credentials --name
                       --resource-group
                       [--admin]
                       [--context]
                       [--file]
                       [--format]
                       [--overwrite-existing]
                       [--public-fqdn]

Examples

Get access credentials for a managed Kubernetes cluster. (autogenerated)

az aks get-credentials --name MyManagedCluster --resource-group MyResourceGroup

Required Parameters

--name -n

Name of the managed cluster.

--resource-group -g

Name of resource group. You can configure the default group using az configure --defaults group=<name>.

Optional Parameters

--admin -a

Get cluster administrator credentials. Default: cluster user credentials.

default value: False
--context

If specified, overwrite the default context name. The --admin parameter takes precedence over --context.

--file -f

Kubernetes configuration file to update. Use "-" to print YAML to stdout instead.

default value: ~\.kube\config
--format

Specify the format of the returned credential. Available values are ["exec", "azure"]. Only take effect when requesting clusterUser credential of AAD clusters.

--overwrite-existing

Overwrite any existing cluster entry with the same name.

default value: False
--public-fqdn

Get private cluster credential with server address to be public fqdn.

default value: False
Global Parameters
--debug

Increase logging verbosity to show all debug logs.

--help -h

Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.

--query

JMESPath query string. See http://jmespath.org/ for more information and examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az account set -s NAME_OR_ID.

--verbose

Increase logging verbosity. Use --debug for full debug logs.

 

Splunk Enterprise update plan

Splunk published this awesome Splunk Enterprise update plan: https://docs.splunk.com/images/d/d3/Splunk_upgrade_order_of_ops.pdf 

Regardless if you have a single-site or multi-site splunk installation, if your are running a stand-alone or distributed and/or clustered architecture, if you are using Splunks Universal Forwarder, the Deployment server, a License Master, Search Head cluster or Indexer Cluster master or not - this plan has your environment setup covered.

Step by step it guides you in updating your Splunk Enterprise environment including backuping up every system, checking each systems health and possible connectivity issues as well as the updates itself, may it be a simple upgrade or a rolling upgrade. Additional informations about each step can be found in the PDF as a link to docs.splunk.com.

Splunk Enterprise update plan step by step


 

How to increase IT security of a company using quick wins

How to increase my companys IT security? Of course there are many, many, many topics, processes, systems, parameters, awareness and a lot more to implement, adjust, train, improve or get rid of. Following the different available frameworks like MITREs Att&ck, the recommendations from NIST or BSI etc will get you there. However they require a lot of time and some companys want to implement some 'quick wins', before they do they adopt a whole framework (which they should).

So some of those 'quick wins' are:
  • Implement Multi-Factor-Auth or 2FA. Trying to balance security with comfort will let you win your users, for example by implementing MFA or 2FA using PushTokens. 
  • Raising awareness by regularly sending internal phishing mails will make them learn and understand, not to open or click on everything. 
  • Implementing zero trust or microsegmentation will make lateral movement hard. 
  • Regularly scanning your whole environment for vulnerabilities and configurations issues with regular patching and improving hardening will dramatically reduce your attack surface.
  • Restrict administrative permissions, regularly checking if they are still necessary, implementing JIT and securing your directory services using special jump servers with MFA/2FA will help further. Also don't use Microsofts AD Built-in default groups because very often the have to many unnecessary permissions

Some more are described in an article from Microsoft security blog. I personally don't agree on all of them, but it is a possible approach:

Picture from https://www.microsoft.com/security/blog/2020/03/05/human-operated-ransomware-attacks-a-preventable-disaster/
(Picture from Microsoft security blog)
 
 
Keeping in mind the point of view from an attacker might help:
Picture from https://www.microsoft.com/security/blog/2020/03/05/human-operated-ransomware-attacks-a-preventable-disaster/
 (Picture from Microsoft security blog)

SIEM IoC regsvr32.exe outbound network connection

An easy to find possible indicator of compromise (IoC) for your SIEM, AEP or EDR could be a outbound network connection from Windows own register server regsvr32.exe (Microsoft Docs or Wiki). Normally the register server never establishes an outbound network connection to the internet. It is a commonly used evasion technique to avoid detection and has its own MITRE Att&ck technique with ID T1117 (or new sub-techniques T1218/010 and can be mapped to the MITRE Att&ck tactics Execution TA0002 and Defense Evasion TA0005.

A starting point can be searching your SIEM logs for network connections from regsvr32.exe to a not RFC1918 private ip address and your IPv6 address space.

Mitigations could be using the Windows firewall to block outbound network connections from regsvr32.exe or as MITRE Att&ck writes:

"Microsoft's Enhanced Mitigation Experience Toolkit (EMET) Attack Surface Reduction (ASR) feature can be used to block regsvr32.exe from being used to bypass whitelisting. Identify and block potentially malicious software executed through regsvr32 functionality by using application whitelisting tools, like Windows Defender Application Control, AppLocker, or Software Restriction Policies where appropriate."

More useful searches for Splunk & Sysmon environments can be found on Github, example: https://github.com/mitre-attack/car/issues/11 and testing if your AEP/EDR/Sysmon or log-collection-tool actually logs regsvr32 events is described here: https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1117/T1117.md
 

Sysmon 11 released

Many SIEM installations use sysinternals sysmon as one of many data sources. Mark Russinovich (Microsoft Azure CTO, co-creator of sysinternals) released a video explaining some of the new features of Sysmon 11, which was released on 28th April.

A new useful feature is archiving a file, just before it is deleted. Some attackers delete their tools after gathering information. In order to understand their tools or even search for MD5 or imphashes, the sysmon 11 archiving function can be helpful.


(Source: https://www.youtube.com/watch?v=_MUP4tgdM7s)

Small/Medium Businesses - New network devices (switches, routers,..) - Minimum ToDo list

Most small/medium businesses don't do much configuration, monitoring, cfg-baselineing or follow best practises with their network devices like switches, routers, wireless controllers, access points etc. Here is a short list of things you should do at minimum:

1. Extend your monitoring of your network devices

Not only ping them, check their uptime by snmp, but:
1.1 Monitor all uplinks (e.g. SNMP bandwidth)
1.2 Monitor all important ports (ports of the servers, firewalls, storage, etc; again e.g. with SNMP bandwidth)
1.3 Monitor device health, fan status, temperature, etc
1.4 Monitor the routing table, especially if you use dynamic routing protocols and/or have many routes
1.5 Monitor utilization of cpu, mem, i/o, etc..
1.6 Monitor everything with secure protocols like SSH, SNMPv3 AuthPriv AES+SHA
1.7 Send SNMP traps from devices to your monitoring system
1.8 Send Syslog from your devices to your monitoring system & logging solution

2. Harden your network

2.1 Disable telnet
2.2 Disable http
2.3 Implement ACLs for allowing access only from dedicated trusted hosts
2.4 Implement ACLs for dynamics routing protocols like BGP, OSPF, etc
2.5 Use LDAPS/Radius authentication for LDAP/AD-authentication for device mgmt
2.6 Send Syslog from your devices to your monitoring system & logging solution
2.7 Disable SNMPv1/v2c
2.8 Use DHCP-Snooping for Rouge DHCP server protection
2.9 Use ARP Spoofing Protection
2.10 Think about disabling link-layer discovery protocols like LLDP, CDP, EDP, etc
2.11 Allow local admin account login only if LDAPS/Radius server is not reachable
2.12 Delete default users, groups and communities

3. Authentication & dynamische vlan assignment

3.1 Use IEEE 802.1x with certificates (at least two AAA Radius Serves (e.g. FreeRadius) with EAP-TLS)
3.2 Use rfc3580 for dynamic vlan assignment
3.3 Think about using either a quarantine fallback vlan for not authenticated clients or a guest vlan with internet access only
3.4 Think of using DHCP Snooping (forwarding) for your devices which does device fingerprinting

4. Documentation

4.1 Create a layer1 and layer2 network plan (e.g. in visio)
4.2 Create a layer2 and layer3 network plan (e.g. in visio)
4.3 Use the l2&l3 plan as background for your monitoring system in a map to have a live-overview

5. Testing

5.1 Test your loop protection (m/r/stp, loop-protect, elrp, + broadcast limit thresholds like max 200 broadcasts per second, etc) in a maintenance window
5.2 Test your "CrossVlan Protection" in a maintenace window. By "CrossVlan" I mean not wanted connections between to vlans, which should be separated (m/r/stp, loop-protect, extra VLAN which is tagged on all ports and sends ELRP or similar loop protection protocols, etc)
5.3 Test your monitoring alerting - is an alert really send when e.g. an important uplink is full or disconnected, if an important lacp lag is down, etc (test using simulation, e.g. via jPerf, Observer etc)
5.4 Check and test if all best practises of the vendor are applied

6. IP-Subnetting

Yes, so many small and medium companys still have a huge flat layer2 network per site :(
6.1 The more subnets, the more a network issue stays only in that tiny subnet
6.2 The smaller the subnet, the less background noise
6.3 Microsegmentation is key! The smaller the subnet and the more it is separated (using private vlans, ACLs, a firewall, filtering device, host firewalls, a microsegmentation solution, NSX-T or something similar), the more it is protected and lateral movement gets harder.

There are many more things, like using LACP instead of static link aggregation groups, using LACP Mode Fast instead of the default slow, using Bidirectional Forwarding Detection "BFD" for everything, using multi-chassis link-aggregation (like MC-LAG, MLAG, etc) instead of Stacking (firmware-updates & reboots mostly cost the whole stack-topology to reboot, which is not the case in MLAG), using Out of Band management, and much more.

The listed items are the things which should be done at minimum.

Malware using PowerShell - PowerShell Logging "Script Block Logging"

More and more so called "fileless malware" uses powershell in order to execute malicious actions. In order to find possible malicious powershell commands or ps-scripts, it is very useful to log them, automatically send them to your SIEM and analyze them. Also if possible, disable Powershell for your users, but this is in the real-world sometimes hard or even not possible.

1. Disable PowerShell for users if possible via GPO
2. Fileless malware using PowerShell - PowerShell Logging using Script Block Logging

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-6#enabling-script-block-logging


Enabling Script Block Logging

When you enable Script Block Logging, PowerShell records the content of all script blocks that it processes. Once enabled, any new PowerShell session logs this information. It's recommended to enable Protected Event Logging.

Using Group Policy

To enable automatic transcription, enable the Turn on PowerShell Script Block Logging feature in Group Policy through Administrative Templates -> Windows Components -> Windows PowerShell.

Using the Registry

Run the following function:
PowerShell
function Enable-PSScriptBlockLogging
{
    $basePath = 'HKLM:\Software\Policies\Microsoft\Windows' +
      '\PowerShell\ScriptBlockLogging'

    if(-not (Test-Path $basePath))
    {
        $null = New-Item $basePath -Force
    }

    Set-ItemProperty $basePath -Name EnableScriptBlockLogging -Value "1"
}
 
Powershell-Commands will be logged in Windows Eventlog with Event-ID 4104.

Monitor UniFi WLAN Access Point with PRTG with SNMPv3 Auth+Encrypted

This is a tiny guide howto monitor your UniFi wireless accesspoint, in this case a Unifi U7 pro with SNMPv3 with AES-Encryption and SHA-Auth...