Skip to content
This repository has been archived by the owner on Aug 5, 2024. It is now read-only.

EventCode and PacketCode are not properly parsed out of DNS Analytical etl logs #15

Open
reswob10 opened this issue Nov 14, 2020 · 0 comments

Comments

@reswob10
Copy link

A couple of issues when this is pointed to the DNS Analytical log (Microsoft-Windows-DNS-Server/Analytical).
First it appears the incorrect EventCode (EventID) is selected. Below is what I receive in Splunk:

11/14/2020 02:27:04 PM
LogName=SilkService-Log
SourceName=SilkService Collector
EventCode=3
EventType=4
Type=Information
ComputerName=TitansTower.titans.local
TaskCategory=None
OpCode=Info
RecordNumber=354488
Keywords=Classic
Message={"ProviderGuid":"eb79061a-a566-4698-9119-3ed2807060e7","YaraMatch":[],"ProviderName":"Microsoft-Windows-DNSServer","EventName":"RECURSE_QUERY","Opcode":0,"OpcodeName":"Info","TimeStamp":"2020-11-14T14:27:02.9641148-08:00","ThreadID":4284,"ProcessID":2772,"ProcessName":"dns","PointerSize":8,"EventDataLength":236,"XmlEventData":{"FormattedMessage":"RECURSE_RESPONSE_IN: TCP=0; Source=8.8.8.8; InterfaceIP=0.0.0.0; AA=0; AD=0; QNAME=www.shadowtrackers.net.; QTYPE=1; XID=16,962; RemoteQueriesSent=1; Port=0; Flags=33,152; RecursionScope=.; CacheScope=Default; PacketData=42428180000100010000000103777777...; AdditionalInfo = VirtualizationInstance: .; GUID={9A8C1E76-A5AF-4590-8DDD-62C3FA22D45F} ","RecursionScope":".","PacketData":"42428180000100010000000103777777...","TCP":"0","GUID":"{9A8C1E76-A5AF-4590-8DDD-62C3FA22D45F}","Flags":"33,152","AD":"0","QNAME":"www.shadowtrackers.net.","CacheScope":"Default","XID":"16,962","MSec":"414994050.4369","Source":"8.8.8.8","AA":"0","Port":"0","QTYPE":"1","PID":"2772","AdditionalInfo":".","RecursionDepth":"1","TID":"4284","ProviderName":"Microsoft-Windows-DNSServer","PName":"","InterfaceIP":"0.0.0.0","EventName":"RECURSE_QUERY"}}

Please note that the EventCode is set to 3. But the above event (seen in the attached png file) is correctly 261:

DNS_Analytical_RECOURSE_RESPONSE_IN

Secondly, (and I'm not sure if this is deliberate or not), but the PacketData field is abbreviated. This field is needed in full so that we can decode the data. Is there a way the entire value can be captured and sent?

Thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant