Hi Dan, >From what you said , I suppose Rule 554 ( syscheck_new_entry) , doesn't get the "syscheck-registry New file" entries. That makes registry monitoring (HKEY/.../.../RUN for example) completely useless . I have added various entries under that key and did not get an alert on any of them.
The way this works should be clearly stated not to get false idea that your monitor something which as it proves you don't . Anyway , coming back to the reason I've opened this post , is there a way to get those new registry entries ? The <decoded_as> entries I mentioned are those rules in ossec_rules.xml ,550 to 554 about syscheck ,for which I haven't been able to understand how exactly do the decoders work. What patterns do they match against. Thank you On Dec 16, 10:08 pm, "dan (ddp)" <[email protected]> wrote: > On Tue, Dec 13, 2011 at 5:47 PM, alsdks <[email protected]> wrote: > > Hello Dan, > > > Interestingly, grepping for 'syscheck_integrity_changed' returns > > different files depending platform , whether the source has been > > compiled or not, etc etc. > > That makes sense. > > > > > > > > > > > Here is what I found in an un-compiled ossec source directory , under > > ossec-hids-2.6/src/analysisd/rules.h : > > > #define ROOTCHECK_MOD "rootcheck" > > #define HOSTINFO_NEW "hostinfo_new" > > #define HOSTINFO_MOD "hostinfo_modified" > > #define SYSCHECK_MOD "syscheck_integrity_changed" > > #define SYSCHECK_MOD2 "syscheck_integrity_changed_2nd" > > #define SYSCHECK_MOD3 "syscheck_integrity_changed_3rd" > > #define SYSCHECK_NEW "syscheck_new_entry" > > #define SYSCHECK_DEL "syscheck_deleted" > > > Other than that I could nor find exactly how the > > syscheck_integrity_changed or syscheck_new_entry (etc) are decoding > > events .What are they searching for . > > It's all in the source. > > > > > > > > > > > The blind spot to me is the following : > > > from archives.log I have pinpointed two examples : > > > event message example A): 2011 Dec 13 15:56:51 (wintest) 10.10.10.1- > >>syscheck New file 'C:\Windows/System32/drivers/etc/test.txt' added to > > the file system. > > example B):2011 Dec 09 04:38:56 (wintest) 10.10.10.1->syscheck- > > registry New file 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows > > \CurrentVersion\Uninstall\WinSSHD' added to the file system. > > > Example A has generated an alert as it was expected .Example B hasn't > > although it is specified in agent's ossec.conf to monitor this > > registry key amongst others.(Rule 554 is overwritten to alert new > > files) .A quick eye spotted difference is syscheck in A instead of > > syscheck-registry in B. > > > Question 1: Why example B did not generate an alert .(there are no > > ignore rules for that key) > > What rule should be triggered? I don't know if there is one to alert > on new registry entries. > > > > > > > > > > > Another interesting thing I have noticed , which led me into searching > > the above mentioned decoders, is that if I paste example A again > > through ossec-logtest I get the following : > > > **Phase 1: Completed pre-decoding. > > full event: '2011 Dec 13 15:56:51 (wintest) 10.10.10.1- > >>syscheck New file 'C:\Windows/System32/drivers/etc/test.txt' added to > > the file system.' > > hostname: 'ossec-server' > > program_name: '(null)' > > log: '2011 Dec 13 15:56:51 (wintest) 10.10.10.1->syscheck New > > file 'C:\Windows/System32/drivers/etc/test.txt' added to the file > > system.' > > > **Phase 2: Completed decoding. > > No decoder matched. > > > So there is no alert triggered. > > > Question 2 : were does this get triggered ? Am I seeing an altered > > analysisd > > > event in archives.log ? What are these <decoded_as> entries searching > > Yes, there is a header attached to the log entry. > > > for that did not trigger an alert in example B (ok that was a multi > > question ). > > What <decoded_as> entries? > > > > > > > > > And finally should I be making a custom decoder and rule for example > > B ? > > > I hope I have explained it as clearly as I could , I could be delving > > down the wrong path but I though I needed to find how these decoders > > work > > > Thank you ! > > > On Dec 13, 10:31 pm, "dan (ddp)" <[email protected]> wrote: > >> On Tue, Dec 13, 2011 at 5:23 AM, alsdks <[email protected]> wrote: > > >> > Hello Dan, > > >> > hmmm those are binaries and I can't get anything out of them ... > > >> They should be c source code files. > > >> > The thing is, while troubleshooting my other issue (Syscheck issue on > >> > Windows : alerts not generated for registry and executable checks : > >> > default OSSEC.conf) I have noticed the following behavior : > > >> > While testing messages as they arrive to the system (using logall > >> > option) with ossec-logtest , even messages that have triggered an > >> > alert , it says that 'No decoder found' and further processing is not > >> > done .So I am guessing that processing and triggering the relative > >> > alerts through rules is done elsewhere or with other means . > > >> > It is very strange how it works , and to me this is a blind spot . > > >> What's the blind spot exactly? > > >> > Thank you Dan. > > >> > On Dec 12, 10:06 pm, "dan (ddp)" <[email protected]> wrote: > >> >> src/analysisd/decoders/{decode-xml.c,syscheck.c} > > >> >> On Mon, Dec 12, 2011 at 10:42 AM, alsdks <[email protected]> wrote: > >> >> > Hello list, > > >> >> > rules 550,551,552 specifying integrity checksum alerts call upon > >> >> > decoders that I haven't been able to locate in decoders.xml or > >> >> > anywhere else. > > >> >> > They have : > >> >> > <decoded_as>syscheck_integrity_changed</decoded_as> > >> >> > <decoded_as>syscheck_integrity_changed_2nd</decoded_as> > >> >> > <decoded_as>syscheck_integrity_changed_3rd</decoded_as> > > >> >> > Were are these decoders specified to see what are they searching for , > >> >> > how they decode the event message. > > >> >> > Thank you
