Re: [ossec-list] Re: %AppData% alert on new file creation proper setup

2017-03-27 Thread dan (ddp) 
On Mon, Mar 27, 2017 at 4:26 AM,   wrote:
> Hello Dan,
>
> Thank you for your feedback. I have changed the frequency to 900
> sec, and inspected the ossec.log. I noted that inside the log file none of
> the agent.conf directories where present. Any theories on why the ossec.conf
> syscheck content is showing up in ossec.log, and the agent.conf syscheck is
> not?
>

Can OSSEC read the agent.conf (permissions)?
Is the updated agent.conf transferred to the agent (you can open the
file in a text editor to check)?
Other than that, no real idea.

> cheers,
> Henry
>
> On Saturday, March 25, 2017 at 6:50:03 AM UTC-6, henry.wil...@gmail.com
> wrote:
>>
>> Hello fellow googlers,
>>
>>
>> The GOAL:
>>
>> For every user on my windows OSSEC agent, generate OSSEC alert severity 10
>> when new file added to
>>
>> C:\Users/*/%AppData%/Local/Temp directory
>>
>> Where star was supposed to be the wildcard place holder to instruct OSSEC
>> to mean ANY user
>>
>>
>>
>> The Attempt & RESULTS:
>>
>>
>> In an effort to get OSSEC to generate an alert upon new file created in
>> %AppData% I have conducted the following steps.
>>
>>
>> http://ossec-docs.readthedocs.io/en/latest/faq/syscheck.html#why-aren-t-new-files-creating-an-alert
>>
>> Why aren’t new files creating an alert?
>>
>> By default OSSEC does not alert on new files. To enable this
>> functionality,  must be set to yes inside the 
>> section of the manager’s ossec.conf. Also, the rule to alert on new files
>> (rule 554) is set to level 0 by default. The alert level will need to be
>> raised in order to see the alert. Alerting on new files does not work in
>> realtime, a full scan will be necessary to detect them.
>>
>> Add the following to local_rules.xml:
>>
>> 
>>
>>   ossec
>>
>>   syscheck_new_entry
>>
>>   File added to the system.
>>
>>   syscheck,
>>
>> 
>>
>> The  entry should look something like this:
>>
>> 
>>
>>   7200
>>
>>   yes
>>
>>   /etc,/bin,/sbin
>>
>> 
>>
>>
>>
>> In my OSSEC environment, I have a CENTos (current build) host for my OSSEC
>> manager. I also have windows OS host for my OSSEC agent (agent id=001). To
>> test the agent.conf setup of OSSEC I have on the OSSEC Manger host two
>> configuration files, both the original ossec.conf file located @ directory
>> var/ossec/etc/ as well as the agent.conf file located @ directory
>> var/ossec/etc/shared. I have made the  entry in both these
>> configuration files. As well as add rule id 554 to local_rules.xml as
>> depicted above from OSSEC documentation.
>>
>>
>> To confirm settings are correct I ran logtest without error. Additionally,
>> I preformed the following self-checks:
>>
>>
>> Confirmed level=”10” for rule id 554 in local_rules.xml AND
>> On OSSEC Manager inside the ossec.conf file that setting for alert
>> threshold was set to alert on level>=1
>> Md5sum on Manager = on Agent copy of agent.conf
>> Reduced frequency to 60 for troubleshooting/testing create new file
>> feature.
>> create new file in directory %AppData%  ‘test.txt’
>>
>> No immediate result, additionally let sit and wait for 24hrs to ensure
>> syscheck could run multiple times.
>> Result new file ‘test.txt’ was not alerted on.
>>
>> To arrive at this conclusion, I inspected the following results:
>>
>> nano /var/ossec/logs/alerts/alerts.log
>>
>> I can see .nix directories are firing for rule id 554. However, no
>> %AppData% windows file creation detected.
>>
>> /var/ossec/bin/agent_control -i 001
>> /var/ossec/bin/agent_control -r -u 001
>> /var/ossec/bin/syscheck_control -u 001
>>
>> OUTPUT
>> ** Integrity check database updated.
>>
>> /var/ossec/bin/syscheck_control -i 001
>>
>> OUTPUT
>> Integrity changes for agent 'WinBox (001) - 192.168.0.2':
>> ** No entries found.
>>
>> ls /var/ossec/queue/diff
>>
>> No entries for Windows agent
>>
>> nano /var/ossec/logs/alerts/alerts.log
>>
>>  I am able to see entries for rule id 554 on .nix localhost /tmp test
>> efforts for 554. Other windows content is present such as authentication
>> logs and registry edits. Additionally,I can get C:\Temp new file creation to
>> detect but not any new file alerts for the %AppData%.
>>
>> ls /var/ossec/queue/syscheck/
>>
>> I can see the text files I was testing with from C:\Temp but no %AppData%
>> content.
>>
>>
>>
>> From the above I gather that my test new file creations are being detected
>> and alerted on my localhost. However, the syntax or other issue appears to
>> be causing problems such that the %AppData% directory is not being properly
>> monitored by syscheck as was the case for the C:\Temp directory for example.
>>
>>
>> I am hoping for some guidance on how I go about testing the alert on new
>> file creation for windows OS %AppData% directory. Such as how to confirm
>> windows agent is detecting the new file created, and that the Master OSSEC
>> is receiving this event from the windows agent correctly, then Master OSSEC
>> is alerting on new file detection by rule 554 properly.
>>
>>

Re: [ossec-list] OSSEC Agents Unable to Connect to Server

2017-03-27 Thread dan (ddp) 
On Mon, Mar 27, 2017 at 10:50 AM, Marc Baker  wrote:
> OSSEC agents this morning were working without issue and then began
> reporting as Disconnected. Agent logs are returning the following error:
>
> 2017/03/27 10:14:38 ossec-agent: WARN: Process locked. Waiting for
> permission...
>
> 2017/03/27 10:14:49 ossec-agent(4101): WARN: Waiting for server reply (not
> started). Tried: '.
>
> 2017/03/27 10:14:51 ossec-agent: INFO: Trying to connect to server (:1514).
>
> Nothing has changed on the server to the best of our knowledge. One anomaly
> we are seeing that may be related is the following when restarting Wazuh
> manager services:
>
>
> Deleting PID file '/var/ossec/var/run/ossec-remoted-4816.pid' not used...

Looks like remoted died. You might want to ask about this on the Wazuh
mailing list. They should be able to help you track it down.

> Killing ossec-monitord ..
> Killing ossec-logcollector ..
> ossec-remoted not running ..
> Killing ossec-syscheckd ..
> Killing ossec-analysisd ..
> Killing ossec-maild ..
> Killing ossec-execd ..
> Killing wazuh-modulesd ..
> Wazuh v2.0 Stopped
> Starting Wazuh v2.0 (maintained by Wazuh Inc.)...
> Started wazuh-modulesd...
> Started ossec-maild...
> Started ossec-execd...
> Started ossec-analysisd...
> Started ossec-logcollector...
> Started ossec-remoted...
> Started ossec-syscheckd...
> Started ossec-monitord...
> Completed.
>
>
> /var/ossec/bin/ossec-analysisd -V
> Wazuh v2.0 - Wazuh Inc.
>
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License (version 2) as
> published by the Free Software Foundation. For more details, go to
> http://www.ossec.net/main/license/
>
> /etc/ossec-init.conf
> DIRECTORY="/var/ossec"
> NAME="Wazuh"
> VERSION="v2.0"
> DATE="Wed Mar 15 11:38:44 UTC 2017"
> TYPE="server"
>
> Any suggestions would be greatly appreciated.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] OSSEC alerts on syslog

2017-03-27 Thread dan (ddp) 
On Mon, Mar 27, 2017 at 11:25 AM,   wrote:
> Hi All,
>
> So I am currently still troubleshooting, but noticed that the syslog-ng
> process was listening on 514 TCP, but also had an entry for 514 UDP, which
> is the protocol I've set within my ossec.conf. Could this be part of the
> issue? My guess is that I only want 514 udp listening.
>

Yes, if syslog-ng is utilizing the port, ossec-remoted will not be
able to use it.

> On Thursday, March 16, 2017 at 3:30:46 PM UTC-4, dan (ddpbsd) wrote:
>>
>> On Thu, Mar 16, 2017 at 11:33 AM,   wrote:
>> > Here is the output:
>> >
>> > udp0  0 0.0.0.0:514 0.0.0.0:*
>> > 21090/syslog-ng
>> >
>>
>> So syslog-ng is listening for incoming messages.
>> You'll have to figure out what syslog-ng is doing with the log messages.
>>
>> > This is the only instance...
>> >
>> >
>> > On Wednesday, March 15, 2017 at 2:41:58 PM UTC-4, dan (ddpbsd) wrote:
>> >>
>> >> On Tue, Mar 14, 2017 at 3:37 PM,   wrote:
>> >> > Hello, yes:
>> >> >
>> >> > root@xx:/var/log# netstat -tuna | grep 514
>> >> > tcp0  0 0.0.0.0:514 0.0.0.0:*
>> >> > udp0  0 0.0.0.0:514 0.0.0.0:*
>> >> >
>> >> >
>> >>
>> >> Adding -p to that could tell you the process using that port.
>> >> `netstat -ptuna | grep 514`
>> >>
>> >> Is this securityonion? They may have syslog-ng already listening to the
>> >> network.
>> >>
>> >> >   
>> >> > syslog
>> >> >   161.182.xxx.xxx
>> >> >   161.182.xxx.xxx
>> >> >   
>> >> >
>> >> >
>> >> >
>> >> > On Tuesday, March 14, 2017 at 1:48:17 PM UTC-4, jose wrote:
>> >> >>
>> >> >> Hi, can you verify if the port it’s open?
>> >> >>
>> >> >> [root@wazuh-manager /]# netstat -tuna | grep 514
>> >> >> udp0  0 0.0.0.0:514 0.0.0.0:*
>> >> >>
>> >> >> The symantec ip is allowed in ossec.conf right?
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regards
>> >> >> ---
>> >> >> Jose Luis Ruiz
>> >> >> Wazuh Inc.
>> >> >> jo...@wazuh.com
>> >> >>
>> >> >> On March 14, 2017 at 12:44:07 PM, eholl...@gmail.com
>> >> >> (eholl...@gmail.com)
>> >> >> wrote:
>> >> >>
>> >> >> It's very strange...I have enabled already enabled syslog over 514
>> >> >> from
>> >> >> our symantec server to the OSSEC server, and I see the logs coming
>> >> >> into
>> >> >> our
>> >> >> ELSA instance, but I have grep'd our syslog files, OSSEC archive and
>> >> >> OSSEC
>> >> >> alerts files and do not see the log anywhere on the server... Where
>> >> >> should
>> >> >> these logs be written when being sent to the server? I've checked
>> >> >> all
>> >> >> gzipped files in /var/log/ as well as all files in
>> >> >> /var/ossec/logs/archive/
>> >> >> and /var/ossec/logs/alerts/
>> >> >>
>> >>
>> >> `/var/ossec/logs/archives/archives.log` only contains entries if you
>> >> enable the logall option in the ossec.conf.
>> >> I'm not sure if it records messages sent to the syslog remoted stuff.
>> >> I just haven't tested it.
>> >>
>> >> >> On Tuesday, March 14, 2017 at 11:44:36 AM UTC-4, jose wrote:
>> >> >>>
>> >> >>> Hello,
>> >> >>>
>> >> >>> In order to permit Ossec recibe your Symantec syslogs messages, you
>> >> >>> need
>> >> >>> to enable this in the configuration:
>> >> >>>
>> >> >>> Listen in port 514:
>> >> >>>
>> >> >>> 
>> >> >>>   
>> >> >>> syslog
>> >> >>>   Symantec AV ip
>> >> >>>   
>> >> >>> 
>> >> >>>
>> >> >>> then you need to restart ossec:
>> >> >>>
>> >> >>> /var/ossec/bin/ossec-control restart
>> >> >>>
>> >> >>> If after these changes you are still not receiving alerts, enable
>> >> >>> logall
>> >> >>> in ossec.conf  yes  and take a look in the file
>> >> >>> “/var/ossec/logs/archives/archives.log”, if the logs are in this
>> >> >>> file,
>> >> >>> but
>> >> >>> not in your alerts, probably the decoders or rules have something
>> >> >>> wrong.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> Regards
>> >> >>> ---
>> >> >>> Jose Luis Ruiz
>> >> >>> Wazuh Inc.
>> >> >>> jo...@wazuh.com
>> >> >>>
>> >> >>> On March 14, 2017 at 10:57:55 AM, eholl...@gmail.com
>> >> >>> (eholl...@gmail.com)
>> >> >>> wrote:
>> >> >>>
>> >> >>> Hello All,
>> >> >>>
>> >> >>> I have pointed my Symantec AV logs to our OSSEC server via syslog
>> >> >>> over
>> >> >>> port 514. I am seeing the logs come into ELSA, but not as OSSEC
>> >> >>> alerts. I
>> >> >>> have created a custom decoder and parser, and can confirm that it
>> >> >>> is
>> >> >>> working:
>> >> >>>
>> >> >>> **Phase 2: Completed decoding.
>> >> >>>decoder: 'Symantec'
>> >> >>>
>> >> >>> **Phase 3: Completed filtering (rules).
>> >> >>>Rule id: '16'
>> >> >>>Level: '7'
>> >> >>>Description: 'Symantec: virus found'
>> >> >>> **Alert to be generated.
>> >> >>>
>> >> >>> Do I need to point OSSEC to monitor the incoming syslog so that it
>> >> >>> can
>> >> >>> alert on it? Again, I am seeing the straight syslog coming into
>> >> >>>

Re: [ossec-list] Can the windows agent report to Wazuh and OSSIM simultaneously?

2017-03-27 Thread dan (ddp) 
On Mon, Mar 27, 2017 at 12:52 PM, Joel Fries  wrote:
> Am I able to setup the OSSEC windows agent to report to both a Wazuh and a
> OSSIM server at the same time?
>

There is no support in the OSSEC agent to report to 2 destinations
simultaneously. It is possible that Wazuh has that capability. OSSEC
server has hybrid mode, which could forward alerts to OSSIM.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ossec-list] Can the windows agent report to Wazuh and OSSIM simultaneously?

2017-03-27 Thread Joel Fries 
Am I able to setup the OSSEC windows agent to report to both a Wazuh and a 
OSSIM server at the same time?

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] OSSEC alerts on syslog

2017-03-27 Thread ehollis3942 
Hi All,

So I am currently still troubleshooting, but noticed that the syslog-ng 
process was listening on 514 TCP, but also had an entry for 514 UDP, which 
is the protocol I've set within my ossec.conf. Could this be part of the 
issue? My guess is that I only want 514 udp listening.

On Thursday, March 16, 2017 at 3:30:46 PM UTC-4, dan (ddpbsd) wrote:
>
> On Thu, Mar 16, 2017 at 11:33 AM,   
> wrote: 
> > Here is the output: 
> > 
> > udp0  0 0.0.0.0:514 0.0.0.0:* 
> > 21090/syslog-ng 
> > 
>
> So syslog-ng is listening for incoming messages. 
> You'll have to figure out what syslog-ng is doing with the log messages. 
>
> > This is the only instance... 
> > 
> > 
> > On Wednesday, March 15, 2017 at 2:41:58 PM UTC-4, dan (ddpbsd) wrote: 
> >> 
> >> On Tue, Mar 14, 2017 at 3:37 PM,   wrote: 
> >> > Hello, yes: 
> >> > 
> >> > root@xx:/var/log# netstat -tuna | grep 514 
> >> > tcp0  0 0.0.0.0:514 0.0.0.0:* 
> >> > udp0  0 0.0.0.0:514 0.0.0.0:* 
> >> > 
> >> > 
> >> 
> >> Adding -p to that could tell you the process using that port. 
> >> `netstat -ptuna | grep 514` 
> >> 
> >> Is this securityonion? They may have syslog-ng already listening to the 
> >> network. 
> >> 
> >> >
> >> > syslog 
> >> >   161.182.xxx.xxx 
> >> >   161.182.xxx.xxx 
> >> >
> >> > 
> >> > 
> >> > 
> >> > On Tuesday, March 14, 2017 at 1:48:17 PM UTC-4, jose wrote: 
> >> >> 
> >> >> Hi, can you verify if the port it’s open? 
> >> >> 
> >> >> [root@wazuh-manager /]# netstat -tuna | grep 514 
> >> >> udp0  0 0.0.0.0:514 0.0.0.0:* 
> >> >> 
> >> >> The symantec ip is allowed in ossec.conf right? 
> >> >> 
> >> >> 
> >> >> 
> >> >> Regards 
> >> >> --- 
> >> >> Jose Luis Ruiz 
> >> >> Wazuh Inc. 
> >> >> jo...@wazuh.com 
> >> >> 
> >> >> On March 14, 2017 at 12:44:07 PM, eholl...@gmail.com 
> >> >> (eholl...@gmail.com) 
> >> >> wrote: 
> >> >> 
> >> >> It's very strange...I have enabled already enabled syslog over 514 
> from 
> >> >> our symantec server to the OSSEC server, and I see the logs coming 
> into 
> >> >> our 
> >> >> ELSA instance, but I have grep'd our syslog files, OSSEC archive and 
> >> >> OSSEC 
> >> >> alerts files and do not see the log anywhere on the server... Where 
> >> >> should 
> >> >> these logs be written when being sent to the server? I've checked 
> all 
> >> >> gzipped files in /var/log/ as well as all files in 
> >> >> /var/ossec/logs/archive/ 
> >> >> and /var/ossec/logs/alerts/ 
> >> >> 
> >> 
> >> `/var/ossec/logs/archives/archives.log` only contains entries if you 
> >> enable the logall option in the ossec.conf. 
> >> I'm not sure if it records messages sent to the syslog remoted stuff. 
> >> I just haven't tested it. 
> >> 
> >> >> On Tuesday, March 14, 2017 at 11:44:36 AM UTC-4, jose wrote: 
> >> >>> 
> >> >>> Hello, 
> >> >>> 
> >> >>> In order to permit Ossec recibe your Symantec syslogs messages, you 
> >> >>> need 
> >> >>> to enable this in the configuration: 
> >> >>> 
> >> >>> Listen in port 514: 
> >> >>> 
> >> >>>  
> >> >>>
> >> >>> syslog 
> >> >>>   Symantec AV ip 
> >> >>>
> >> >>>  
> >> >>> 
> >> >>> then you need to restart ossec: 
> >> >>> 
> >> >>> /var/ossec/bin/ossec-control restart 
> >> >>> 
> >> >>> If after these changes you are still not receiving alerts, enable 
> >> >>> logall 
> >> >>> in ossec.conf  yes  and take a look in the file 
> >> >>> “/var/ossec/logs/archives/archives.log”, if the logs are in this 
> file, 
> >> >>> but 
> >> >>> not in your alerts, probably the decoders or rules have something 
> >> >>> wrong. 
> >> >>> 
> >> >>> 
> >> >>> 
> >> >>> Regards 
> >> >>> --- 
> >> >>> Jose Luis Ruiz 
> >> >>> Wazuh Inc. 
> >> >>> jo...@wazuh.com 
> >> >>> 
> >> >>> On March 14, 2017 at 10:57:55 AM, eholl...@gmail.com 
> >> >>> (eholl...@gmail.com) 
> >> >>> wrote: 
> >> >>> 
> >> >>> Hello All, 
> >> >>> 
> >> >>> I have pointed my Symantec AV logs to our OSSEC server via syslog 
> over 
> >> >>> port 514. I am seeing the logs come into ELSA, but not as OSSEC 
> >> >>> alerts. I 
> >> >>> have created a custom decoder and parser, and can confirm that it 
> is 
> >> >>> working: 
> >> >>> 
> >> >>> **Phase 2: Completed decoding. 
> >> >>>decoder: 'Symantec' 
> >> >>> 
> >> >>> **Phase 3: Completed filtering (rules). 
> >> >>>Rule id: '16' 
> >> >>>Level: '7' 
> >> >>>Description: 'Symantec: virus found' 
> >> >>> **Alert to be generated. 
> >> >>> 
> >> >>> Do I need to point OSSEC to monitor the incoming syslog so that it 
> can 
> >> >>> alert on it? Again, I am seeing the straight syslog coming into 
> ELSA, 
> >> >>> but no 
> >> >>> OSSEC alert appears to be generated. 
> >> >>> 
> >> >>> Thanks 
> >> >>> -- 
> >> >>> 
> >> >>> --- 
> >> >>> You received this message because you are subscribed to the Google 
>

[ossec-list] OSSEC Agents Unable to Connect to Server

2017-03-27 Thread Marc Baker 
OSSEC agents this morning were working without issue and then began 
reporting as Disconnected. Agent logs are returning the following error:

2017/03/27 10:14:38 ossec-agent: WARN: Process locked. Waiting for 
permission...

2017/03/27 10:14:49 ossec-agent(4101): WARN: Waiting for server reply (not 
started). Tried: '.

2017/03/27 10:14:51 ossec-agent: INFO: Trying to connect to server (:1514).

Nothing has changed on the server to the best of our knowledge. One anomaly 
we are seeing that may be related is the following when restarting Wazuh 
manager services:


*Deleting PID file '/var/ossec/var/run/ossec-remoted-4816.pid' not used...*
Killing ossec-monitord ..
Killing ossec-logcollector ..
ossec-remoted not running ..
Killing ossec-syscheckd ..
Killing ossec-analysisd ..
Killing ossec-maild ..
Killing ossec-execd ..
Killing wazuh-modulesd ..
Wazuh v2.0 Stopped
Starting Wazuh v2.0 (maintained by Wazuh Inc.)...
Started wazuh-modulesd...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.


/var/ossec/bin/ossec-analysisd -V
Wazuh v2.0 - Wazuh Inc.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License (version 2) as
published by the Free Software Foundation. For more details, go to
http://www.ossec.net/main/license/

/etc/ossec-init.conf
DIRECTORY="/var/ossec"
NAME="Wazuh"
VERSION="v2.0"
DATE="Wed Mar 15 11:38:44 UTC 2017"
TYPE="server"

Any suggestions would be greatly appreciated.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ossec-list] Re: %AppData% alert on new file creation proper setup

2017-03-27 Thread henry . williamsgroup 
Hello Dan,

Thank you for your feedback. I have changed the frequency to 900 
sec, and inspected the ossec.log. I noted that inside the log file none of 
the agent.conf directories where present. Any theories on why the 
ossec.conf syscheck content is showing up in ossec.log, and the agent.conf 
syscheck is not? 

cheers,
Henry 

On Saturday, March 25, 2017 at 6:50:03 AM UTC-6, henry.wil...@gmail.com 
wrote:
>
> Hello fellow googlers, 
>
>
> The GOAL:
>
> For every user on my windows OSSEC agent, generate OSSEC alert severity 10 
> when new file added to
>
> C:\Users/*/%AppData%/Local/Temp directory
>
> Where star was supposed to be the wildcard place holder to instruct OSSEC 
> to mean ANY user
>
>
>
> The Attempt & RESULTS:
>
>
> In an effort to get OSSEC to generate an alert upon new file created in 
> %AppData% I have conducted the following steps.
>
>
> http://ossec-docs.readthedocs.io/en/latest/faq/syscheck.html#why-aren-t-new-files-creating-an-alert
>
> Why aren’t new files creating an alert? 
> 
>
> By default OSSEC does not alert on new files. To enable this 
> functionality,  must be set to yes inside the  
> section of the manager’s ossec.conf. Also, the rule to alert on new files 
> (rule 554) is set to level 0 by default. The alert level will need to be 
> raised in order to see the alert. Alerting on new files does not work in 
> realtime, a full scan will be necessary to detect them.
>
> Add the following to local_rules.xml:
>
> **
>
>   **ossec**
>
>   **syscheck_new_entry**
>
>   **File added to the system.**
>
>   **syscheck,**
>
> **
>
> The  entry should look something like this:
>
> **
>
>   **7200**
>
>   **yes**
>
>   **/etc,/bin,/sbin**
>
> **
>
>  
>
> In my OSSEC environment, I have a CENTos (current build) host for my OSSEC 
> manager. I also have windows OS host for my OSSEC agent (agent id=001). To 
> test the agent.conf setup of OSSEC I have on the OSSEC Manger host two 
> configuration files, both the original ossec.conf file located @ directory 
> var/ossec/etc/ as well as the agent.conf file located @ directory 
> var/ossec/etc/shared. I have made the  entry in both these 
> configuration files. As well as add rule id 554 to local_rules.xml as 
> depicted above from OSSEC documentation.
>
>
> To confirm settings are correct I ran logtest without error. Additionally, 
> I preformed the following self-checks:
>
>
>
>- Confirmed level=”10” for rule id 554 in local_rules.xml AND
>- On OSSEC Manager inside the ossec.conf file that setting for alert 
>threshold was set to alert on level>=1
>- Md5sum on Manager = on Agent copy of agent.conf
>- Reduced frequency to 60 for troubleshooting/testing create new file 
>feature.
>- create new file in directory %AppData%  ‘test.txt’
>- No immediate result, additionally let sit and wait for 24hrs to 
>   ensure syscheck could run multiple times.
>   - Result new file ‘test.txt’ was not alerted on.
>
> To arrive at this conclusion, I inspected the following results:
>
>- nano /var/ossec/logs/alerts/alerts.log
>- I can see .nix directories are firing for rule id 554. However, no 
>   %AppData% windows file creation detected.
>- /var/ossec/bin/agent_control -i 001
>- /var/ossec/bin/agent_control -r -u 001
>- /var/ossec/bin/syscheck_control -u 001
>- OUTPUT
>   - ** Integrity check database updated.
>- /var/ossec/bin/syscheck_control -i 001
>- OUTPUT
>   - Integrity changes for agent 'WinBox (001) - 192.168.0.2':
>   - ** No entries found.
>- ls /var/ossec/queue/diff
>- No entries for Windows agent 
>- nano /var/ossec/logs/alerts/alerts.log
>-  I am able to see entries for rule id 554 on .nix localhost /tmp 
>   test efforts for 554. Other windows content is present such as 
>   authentication logs and registry edits. Additionally,I can get C:\Temp 
> new 
>   file creation to detect but not any new file alerts for the %AppData%.
>- ls /var/ossec/queue/syscheck/
>- I can see the text files I was testing with from C:\Temp but no 
>   %AppData% content.
>
>
>
> From the above I gather that my test new file creations are being detected 
> and alerted on my localhost. However, the syntax or other issue appears to 
> be causing problems such that the %AppData% directory is not being properly 
> monitored by syscheck as was the case for the C:\Temp directory for 
> example. 
>
>
> I am hoping for some guidance on how I go about testing the alert on new 
> file creation for windows OS %AppData% directory. Such as how to confirm 
> windows agent is detecting the new file created, and that the Master OSSEC 
> is receiving this event from the windows agent correctly, then Master OSSEC 
> is alerting on new file detection by rule 554 properly.
>
> The other threads