Mechanism for tracing direct machine logins

[sxa]

For Linux/UNIX-based systems we use ssh keys to control log-ins to the server. Currently we do not log the keys used to log into the system which is beneficial from an audit perspective.

A SHA256 fingerprint of the keys used for successful connections are typically written to the SSH log file (e.g. /var/log/auth.log). ssh-keygen -l -f [keys_file] can be used to show the fingerprints of each key in the authorized_keys file. We can therefore tell which keys were used to log into the machines and potentially store them in a central location for analysis to identify unexpected access patterns. Wazuh could be likely be ideal for tracking this #3162.

[steelhead31]

The following is an example of a successful login via ssh in Wazuh..

`

@timestamp | 2023-10-31T10:43:45.143Z
-- | -- | --
  | GeoLocation.city_name | Sheffield
  | GeoLocation.country_name | United Kingdom
  | GeoLocation.location.lat | 53.3376
  | GeoLocation.location.lon | -1.4771
  | GeoLocation.region_name | Sheffield
  | _id | nkFVhYsBh4t68z4XEqKQ
  | agent.id | 001
  | agent.ip | 172.31.1.100
  | agent.name | nagios
  | data.dstuser | root
  | data.srcip | 92.237.81.75
  | data.srcport | 60900
  | decoder.name | sshd
  | decoder.parent | sshd
  | full_log | Oct 31 11:43:44 nagios sshd[3881232]: Accepted publickey for root from 92.237.81.75 port 60900 ssh2: RSA SHA256:xxxxxxxxxxxxxxxxxxxxxREDACTEDxxxxxxxxxxxxxxxxxxxxxxxxxxx
  | id | 1698749025.1164333527
  | input.type | log
  | location | /var/log/auth.log
  | manager.name | infra-wazuh-server
  | predecoder.hostname | nagios
  | predecoder.program_name | sshd
  | predecoder.timestamp | Oct 31 11:43:44
  | rule.description | sshd: authentication success.
  | rule.firedtimes | 30
  | rule.gdpr | IV_32.2
  | rule.gpg13 | 7.1, 7.2
  | rule.groups | syslog, sshd, authentication_success
  | rule.hipaa | 164.312.b
  | rule.id | 5715
  | rule.level | 3
  | rule.mail | false
  | rule.mitre.id | T1078, T1021
  | rule.mitre.tactic | Defense Evasion, Persistence, Privilege Escalation, Initial Access, Lateral Movement
  | rule.mitre.technique | Valid Accounts, Remote Services
  | rule.nist_800_53 | AU.14, AC.7
  | rule.pci_dss | 10.2.5
  | rule.tsc | CC6.8, CC7.2, CC7.3
  | timestamp | 2023-10-31T10:43:45.143+0000

`

[steelhead31]

Below is how I've configured a custom decoder for extracting additional information from the auth.log in Wazuh. This example works for a log file that is already ingested by Wazuh. If reading in a new log file, additional steps will be needed...

1. Identify a sample log entry ( this is from an auth.log file (

xxxxx sshd[1914646]: Accepted publickey for nagios from 178.62.115.224 port 37010 ssh2: RSA SHA256:XXXXXXXXX

2. Add the below section to the Wazuh server local decoder config file: /var/ossec/etc/decoders/local_decoder.xml, please note the comment lines, to provide clarity and details on what the decoder is for.

<!-- Custom Decoder For SSH Capturing KEY Hash -->
<!-- Example log entry: xxxxx sshd[1914646]: Accepted publickey for nagios from 178.62.115.224 port 37010 ssh2: RSA SHA256:XXXXXXXXX -->
<!-- Example log can be used with Wazuh logtest utility -->

<decoder name="ssh-with-key">
       <prematch>\S+ sshd[\d+]:</prematch>
       <regex offset="after_prematch"> (\S+) publickey for (\.+) from (\.+) port (\.+) ssh2: RSA SHA256:(\.+)</regex>
        <order>status, user, ipaddress, port, SHA256</order>
</decoder>

3. Add a custom rule ( Note Use ID numbers between 100000 and 120000 for custom rules. ) to the Wazuh server custom rules file /var/ossec/etc/rules/local_rules.xml

<group name="custom_rules,">
  <rule id="100010" level="10">
    <decoded_as>ssh-with-key</decoded_as>
    <description>SSH With Valid Key</description>
  </rule>
</group>

4. Run the test log line though the Wazuh logtest program ( /var/ossec/bin/wazuh-logtest )

Starting wazuh-logtest v4.5.3
Type one log per line

xxxxx sshd[1914646]: Accepted publickey for nagios from 178.62.115.224 port 37010 ssh2: RSA SHA256:XXXXXXXXX

**Phase 1: Completed pre-decoding.
	full event: 'xxxxx sshd[1914646]: Accepted publickey for nagios from 178.62.115.224 port 37010 ssh2: RSA SHA256:XXXXXXXXX'

**Phase 2: Completed decoding.
	name: 'ssh-with-key'
	SHA256: 'XXXXXXXXX'
	dstuser: 'nagios'
	ipaddress: '178.62.115.224'
	port: '37010'
	status: 'Accepted'

**Phase 3: Completed filtering (rules).
	id: '100010'
	level: '10'
	description: 'SSH With Valid Key'
	groups: '['custom_rules']'
	firedtimes: '1'
	mail: 'False'
**Alert to be generated.

[steelhead31]

I have this configured and working for ssh logins in Wazuh, not using the custom rule above, as that doesn't work in practice, though it does in test :), there is a difference between adding a new custom decoder ( as shown in the example above ) and extending an existing decoder and alert.. the process is subtly different... here's how I got this to work... the process below should ensure that the custom rules do not get overwritten by future updates...

This example shows the extension to the existing sshd-success decoder

1. Copy the existing decoder file from Wazuh into the custom decoders location

cp /var/ossec/ruleset/decoders/0310-ssh_decoders.xml /var/ossec/etc/decoders/

2. Edit the /var/ossec/etc/ossec.conf to disable the system default decoder, the following line is added..

<decoder_exclude>ruleset/decoders/0310-ssh_decoders.xml</decoder_exclude>

<ruleset>
    <!-- Default ruleset -->
    <decoder_dir>ruleset/decoders</decoder_dir>
    <rule_dir>ruleset/rules</rule_dir>
    <rule_exclude>0215-policy_rules.xml</rule_exclude>
    <list>etc/lists/audit-keys</list>
    <list>etc/lists/amazon/aws-eventnames</list>
    <list>etc/lists/security-eventchannel</list>

    <!-- User-defined ruleset -->
    <decoder_dir>etc/decoders</decoder_dir>
    <rule_dir>etc/rules</rule_dir>
    <decoder_exclude>ruleset/decoders/0310-ssh_decoders.xml</decoder_exclude>
  </ruleset>

3. Update the new custom decoders file created in step 1, (/var/ossec/etc/decoders/0310-ssh_decoders.xml) with the required changes, for this example Im changing the default sshd-success decoder to capture the SSH Key checksum

Replace this:

<decoder name="sshd-success">
  <parent>sshd</parent>
  <prematch>^Accepted</prematch>
  <regex offset="after_prematch">^ \S+ for (\S+) from (\S+) port (\S+)</regex>
  <order>user, srcip, srcport</order>
  <fts>name, user, location</fts>
</decoder>

With this:

<decoder name="sshd-success">
  <parent>sshd</parent>
  <prematch>^Accepted</prematch>
  <regex offset="after_prematch">^ \S+ for (\S+) from (\S+) port (\S+) ssh2: RSA SHA256:(\S+)</regex>
  <order>user, srcip, srcport, keysum</order>
  <fts>name, user, location</fts>
</decoder>

4. Ensure the file permissions are correct on the new decoders file, /var/ossec/etc/decoders/0310-ssh_decoders.xml and restart the Wazuh server

systemctl restart wazuh-manager

5. If the server fails to restart, you can check any errors with the service by running

systemctl status wazuh-manager

Which should highlight any issues with file syntax, permissions etc

6. Finally you can test your changes by using the wazuh-logtest utility....

/var/ossec/bin/wazuh-logtest

And then paste in a full log line to be checked, e.g..

Nov  7 17:02:05 nagios sshd[703148]: Accepted publickey for root from 92.237.81.75 port 51420 ssh2: RSA SHA256:xxxxxxxxxxxxxxxxxxx

Which should return the expected output.. and you can see the new keysum field being captured by Wazuh

**Phase 1: Completed pre-decoding.
	full event: 'Nov  7 17:02:05 nagios sshd[703148]: Accepted publickey for root from 92.237.81.75 port 51420 ssh2: RSA SHA256:xxxxxxxxxxxxxxxxxxx'
	timestamp: 'Nov  7 17:02:05'
	hostname: 'nagios'
	program_name: 'sshd'

**Phase 2: Completed decoding.
	name: 'sshd'
	parent: 'sshd'
	dstuser: 'root'
	keysum: 'xxxxxxxxxxxxxxxxxxx'
	srcip: '92.237.81.75'
	srcport: '51420'

**Phase 3: Completed filtering (rules).
	id: '5715'
	level: '3'
	description: 'sshd: authentication success.'
	groups: '['syslog', 'sshd', 'authentication_success']'
	firedtimes: '1'
	gdpr: '['IV_32.2']'
	gpg13: '['7.1', '7.2']'
	hipaa: '['164.312.b']'
	mail: 'False'
	mitre.id: '['T1078', 'T1021']'
	mitre.tactic: '['Defense Evasion', 'Persistence', 'Privilege Escalation', 'Initial Access', 'Lateral Movement']'
	mitre.technique: '['Valid Accounts', 'Remote Services']'
	nist_800_53: '['AU.14', 'AC.7']'
	pci_dss: '['10.2.5']'
	tsc: '['CC6.8', 'CC7.2', 'CC7.3']'
**Alert to be generated.

[steelhead31]

Here is a screenshot of what I've achieved so far..

[steelhead31]

Added some visualisations, and a new dashboard for this specific task..

And a new dashboard in Wazuh...