Create new rules for `category: network_connection`

[YamatoSecurity]

@fukusuket I noticed that in the recent rule merge, some rules that rely on network connections are now using category: network_connection and therefore can only be detected with Sysmon logs and not the built in logs.

Example:

Before:

title: Suspicious Outbound Kerberos Connection - Security
id: eca91c7c-9214-47b9-b4c5-cb1d7e4f2350
related:
    - id: e54979bd-c5f9-4d6c-967b-a04b19ac4c74
      type: similar
status: test
description: Detects suspicious outbound network activity via kerberos default port indicating possible lateral movement or first stage PrivEsc via delegation.
references:
    - https://github.com/GhostPack/Rubeus
author: Ilyas Ochkov, oscd.community
date: 2019/10/24
modified: 2023/01/30
tags:
    - attack.lateral_movement
    - attack.t1558.003
logsource:
    product: windows
    service: security
detection:
    security:
        Channel: Security
    selection:
        EventID: 5156
        DestPort: 88
    filter_exact:
        Application:
            - C:\Windows\System32\lsass.exe
            - C:\Program Files\Google\Chrome\Application\chrome.exe
            - C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
            - C:\Program Files\Mozilla Firefox\firefox.exe
            - C:\Program Files (x86)\Mozilla Firefox\firefox.exe
    # filter_browsers:
        # Application|endswith:
        #     - '\opera.exe'
        #     - '\tomcat\bin\tomcat8.exe'
    condition: security and (selection and not 1 of filter_*)
falsepositives:
    - Web Browsers
level: high
ruletype: Sigma

After:

title: Uncommon Outbound Kerberos Connection
id: e54979bd-c5f9-4d6c-967b-a04b19ac4c74
related:
    - id: eca91c7c-9214-47b9-b4c5-cb1d7e4f2350
      type: similar
status: test
description: |
    Detects uncommon outbound network activity via Kerberos default port indicating possible lateral movement or first stage PrivEsc via delegation.
references:
    - https://github.com/GhostPack/Rubeus
author: Ilyas Ochkov, oscd.community
date: 2019/10/24
modified: 2024/03/15
tags:
    - attack.credential_access
    - attack.t1558
    - attack.lateral_movement
    - attack.t1550.003
    - sysmon
logsource:
    category: network_connection
    product: windows
detection:
    network_connection:
        EventID: 3
        Channel: Microsoft-Windows-Sysmon/Operational
    selection:
        DestinationPort: 88
        Initiated: 'true'
    filter_main_lsass:
        Image: C:\Windows\System32\lsass.exe
    filter_optional_chrome:
        Image:
            - C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
            - C:\Program Files\Google\Chrome\Application\chrome.exe
    filter_optional_firefox:
        Image:
            - C:\Program Files (x86)\Mozilla Firefox\firefox.exe
            - C:\Program Files\Mozilla Firefox\firefox.exe
    filter_optional_tomcat:
        Image|endswith: \tomcat\bin\tomcat8.exe
    condition: network_connection and (selection and not 1 of filter_main_* and not 1 of filter_optional_*)
falsepositives:
    - Web Browsers and third party application might generate similar activity. An initial baseline is required.
level: medium
ruletype: Sigma

I would like to look into the differences of Sysmon 3 and Security 5156 to see if we can create rules to detect built in logs like we do for process creation and registry.

[fukusuket]

I checked and the differences were as follows. It seems that the conversion is difficult because there are many differences and because the fields that are often used in the Sigma rule are not in Security 5156 :( (Initiated, DestinationHostname, User)

[fukusuket]

Security 5156

https://learn.microsoft.com/ja-jp/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5156

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> 
  <EventID>5156</EventID> 
  <Version>1</Version> 
  <Level>0</Level> 
  <Task>12810</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8020000000000000</Keywords> 
  <TimeCreated SystemTime="2024-07-28T08:21:40.4322268Z" /> 
  <EventRecordID>8514</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="4" ThreadID="480" /> 
  <Channel>Security</Channel> 
  <Computer>samurai</Computer> 
  <Security /> 
  </System>
 <EventData>
  <Data Name="ProcessID">3080</Data> 
  <Data Name="Application">\device\harddiskvolume4\windows\system32\windowspowershell\v1.0\powershell.exe</Data> 
  <Data Name="Direction">%%14593</Data> 
  <Data Name="SourceAddress">10.0.0.4</Data> 
  <Data Name="SourcePort">49775</Data> 
  <Data Name="DestAddress">93.184.215.14</Data> 
  <Data Name="DestPort">443</Data> 
  <Data Name="Protocol">6</Data> 
  <Data Name="FilterRTID">68840</Data> 
  <Data Name="LayerName">%%14611</Data> 
  <Data Name="LayerRTID">48</Data> 
  <Data Name="RemoteUserID">S-1-0-0</Data> 
  <Data Name="RemoteMachineID">S-1-0-0</Data> 
  </EventData>
  </Event>

Sysmon 3

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385f-c22a-43e0-bf4c-06f5698ffbd9}" /> 
  <EventID>3</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>3</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-07-28T08:21:41.7829661Z" /> 
  <EventRecordID>171373</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="3052" ThreadID="3660" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>samurai</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
<EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-07-28 08:21:40.530</Data> 
  <Data Name="ProcessGuid">{09e2f3ec-ff78-66a5-d700-000000000500}</Data> 
  <Data Name="ProcessId">3080</Data> 
  <Data Name="Image">C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Data> 
  <Data Name="User">samurai\samurai</Data> 
  <Data Name="Protocol">tcp</Data> 
  <Data Name="Initiated">true</Data> 
  <Data Name="SourceIsIpv6">false</Data> 
  <Data Name="SourceIp">10.0.0.4</Data> 
  <Data Name="SourceHostname">samurai.g5143yd505qedjc5pchsuhhqtb.mx.internal.cloudapp.net</Data> 
  <Data Name="SourcePort">49775</Data> 
  <Data Name="SourcePortName">-</Data> 
  <Data Name="DestinationIsIpv6">false</Data> 
  <Data Name="DestinationIp">93.184.215.14</Data> 
  <Data Name="DestinationHostname">-</Data> 
  <Data Name="DestinationPort">443</Data> 
  <Data Name="DestinationPortName">https</Data> 
  </EventData>
  </Event>

[YamatoSecurity]

@fukusuket Thanks so much for investigating this! I think we can map the direction of the connection between these logs though. For sysmon, Initiated: true means that it is an outbound connection. This is the same as Direction: %%14593 for Sec 5156 logs. Sysmon's Initiated: false are inbound connections which is the same as Direction: %%14592

Converting rules that rely on DestinationHostname and User will be not possible though. How many rules do not use these fields and how many do?

[fukusuket]

OK! I'll count up those rules :)

[fukusuket]

@YamatoSecurity There are approximately 60 category: network_connection rules, and about 20 of them appear to be convertible :) I'll implement the conversion process💪

There are a few rules that have the following fields added specifically for Aurora Agent?, which cannot be converted (strictly speaking, rules that the original Sysmon cannot detect)

• CommandLine
• ParentImage

[YamatoSecurity]

Thanks! If there are rules that require Aurora Agent then we should probably ignore those and not include in the hayabusa-rules repository as they probably won't be usable anyways without support for reading the Aurora Agent logs.