none
Sysmon - ID 3 - DestinationHostname attribute may mislead analysts RRS feed

  • General discussion

  • Hello,

    Got a case where a sysmon 3 event triggerred a SIEM detection rule for C2 connection based on the IP address. Based on the sysmon 3 event DestinationHostname field, the analyst thought the computer resolved the FQDN given in the DestinationHostname field (because sysmon monitors what's happening on the computer, right?). It turns out that this field is simply a PTR request made by sysmon for every DestinationIP logged in event 3, and the real FQDN used (extracted from Chrome's cache) was not at all the one in DestinationHostname.

    It'd be worth mentionning this fact in the documentation for event 3.


    Configuration:

    <Sysmon schemaversion="4.22">
        <HashAlgorithms>md5,sha256,IMPHASH</HashAlgorithms> <!-- Both MD5 and SHA256 are the industry-standard algorithms for identifying files -->
        <CheckRevocation/> <!-- Check loaded drivers, log if their code-signing certificate has been revoked, in case malware stole one to sign a kernel driver -->
    
        <EventFiltering>
    
        <!--SYSMON EVENT ID 3 : NETWORK CONNECTION INITIATED [NetworkConnect]-->
    
            <!--DATA: UtcTime, ProcessGuid, ProcessId, Image, User, Protocol, Initiated, SourceIsIpv6, SourceIp, SourceHostname, SourcePort, SourcePortName, DestinationIsIpV6, DestinationIp, DestinationHostname, DestinationPort, DestinationPortName-->
        <RuleGroup name="" groupRelation="or">
            <NetworkConnect onmatch="include">
                <Image condition="image">chrome.exe</Image>
                <Image condition="image">sysmon.exe</Image>
            </NetworkConnect>
        </RuleGroup>
    
        </EventFiltering>
    </Sysmon>

    Resulting event content - case 1: PTR exists:

    Network connection detected:
    RuleName:
    UtcTime: 2020-08-24 10:02:09.058
    ProcessGuid: {9B2C28E9-8E1D-5F43-0000-0010644FB800}
    ProcessId: 3428
    Image: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    User: STE\Administrator
    Protocol: udp
    Initiated: 1
    SourceIsIpv6: 0
    SourceIp: 10.233.0.10
    SourceHostname: STE-WKS.STE.LOCAL
    SourcePort: 55148
    SourcePortName:
    DestinationIsIpv6: 0
    DestinationIp: 216.58.213.173
    DestinationHostname: par21s04-in-f173.1e100.net
    DestinationPort: 443
    DestinationPortName: https

    Resulting event content - case 2: PTR does not exist:

    Network connection detected:
    RuleName:
    UtcTime: 2020-08-24 10:13:40.457
    ProcessGuid: {9B2C28E9-8E1D-5F43-0000-0010644FB800}
    ProcessId: 3428
    Image: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    User: STE\Administrator
    Protocol: tcp
    Initiated: 1
    SourceIsIpv6: 0
    SourceIp: 10.233.0.10
    SourceHostname: STE-WKS.STE.LOCAL
    SourcePort: 50974
    SourcePortName:
    DestinationIsIpv6: 0
    DestinationIp: 162.159.136.232
    DestinationHostname:
    DestinationPort: 443
    DestinationPortName: https


    Example:

    In the screenshot below, Chrome was used to browse to discord.com, which resolved to 162.159.137.232, for which there is no PTR record. The DNS cache from Windows has the corresponding entry, so we know it's not used by sysmon.

    A whireshark capture shows DNS PTR queries do stop as soon as sysmon is uninstalled, hence the conclusion that sysmon issues a PTR query to fill its DestinationHostname field.

    Capture of chrome to discord eventlogs vs DNS cache
    Tuesday, August 25, 2020 4:36 PM