OSSEC agent on 64-bit Windows

[bvb09michel]

There is no 64-bit agent for windows!

The 32-bit agent is not able to access the important windows\system32 directory. The same problem exist for access to some important registry hives.
In the ossec.conf file many are active by default of these important entries.
The reason (32-bit application on 64-bit OS) is described here: https://groups.google.com/forum/#!topic/ossec-list/E7YgAoVcFkU

You can show the problem with the telnet.exe. This file only exists in the windows\system32 directory (64 bit exe) and not in the windows\syswow64 directory (32 bit exe) when the Telnet feature is installed.
The telnet.exe file ist configured in the ossec.conf.
Thus appears permanently in the ossec.log the error:
2014/09/08 03:33:18 ossec-agent: WARN: Error opening directory: 'C:\Windows/System32/telnet.exe': No such file or directory
But in reality it exists, of course.

So the problem is, that are not monitored in the windows\system32 directory in reality.
If the monitored file is defined in the ossec.conf, this is monitored in reality in the windows\syswow64 directory.
The same problem applies to the Registry!

[awiddersheim]

Thanks for the information. This is on my short list of things to look at and hopefully fix. Been busy as of late so apologies for the late response.

[bvb09michel]

Thanks for your answer. The problem is that we already use Windows
exclusively 64 bit today (approximately 100,000 clients and 6000 server).
As Microsoft already announced that there will soon be no Windows 32 bit
more!

Many greetings

Michael

Von: awiddersheim [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 06.10.2014 05:29
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

Thanks for the information. This is on my short list of things to look at
and hopefully fix. Been busy as of late so apologies for the late
response.
—
Reply to this email directly or view it on GitHub.

---

Fiducia IT AG
Fiduciastraße 20
76227 Karlsruhe

Sitz der Gesellschaft: Karlsruhe
AG Mannheim HRB 100059

Vorsitzender des Aufsichtsrats: Peter Völker
Vorsitzender des Vorstands: Klaus-Peter Bruns
Vorstand: Jens-Olaf Bartels, Wolfgang Eckert, Carsten Pfläging, Jörg Staff

Umsatzsteuer-ID.Nr. DE143582320, http://www.fiducia.de

[mstarks01]

The solution is definitely to have a 64-bit build, but in the mean time, you should be able to access files in system32 by using %WINDIR%\Sysnative. This is an alias for 32-bit apps provided by Microsoft which is a way into that directory. I'm not sure if there is an equivalent for the registry.

[mstarks01]

This also points out the need to have a customized ossec.conf per Windows platform. Ideally, the installer should be able to detect which Windows version and bitness it is being installed on, and deploy the correct ossec.conf. The binaries and locations for each version may vary slightly so this would ensure a correct and tailored default configuration per environment.

[awiddersheim]

If we were able to make a x64 bit version of the agent would this still be necessary? I'm trying to think of cases but am not coming up with any right now.

[mstarks01]

This one only exists on Vista+ and could be 32-bit or 64-bit: C:\Users/Public/All Users/Microsoft/Windows/Start Menu/Startup, so if the intent is to still support XP, then perhaps it's needed.

Then again, XP? Although the argument could be made that OSSEC is better served on XP since it is more likely to be compromised, I am of the opinion that the Project should not support EOL OSes, which have no more security patches coming. People need motivation to move on and as security professionals, we can help to provide that motivation.

[lostinthetubez]

Be careful with dropping support for Windows XP. POSReady 2009 is basically a slimmed down version of Windows XP and has an EOL of April 9, 2019. Point of sale systems will still be running this OS for many years to come. POSReady may not be an explicitly supported OS, but it is at its core Windows XP, minus a few services and utilities. Being that PCI Compliance is one of the major use cases for OSSEC, the decision to drop Windows XP support should be considered carefully.

[mstarks01]

Those are some good points, @lostinthetubez!

[bvb09michel]

Hello Michael,
thanks for the tip with the sysnative directory. I'm just testing and have
the ossec.conf changed so that the system32 directory the sysnative
directory is used instead. This may be a work around pose for a certain
time for us.
For the registry, you can probably fix the redirection only just by
changing the source code:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129%28v=vs.85%29.aspx

Nevertheless, we need a 64 bit Agent for Windows!
Thanks in advance
regards

Michael

Von: Michael Starks [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 06.10.2014 15:58
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

The solution is definitely to have a 64-bit build, but in the mean time,
you should be able to access files in system32 by using
%WINDIR%\Sysnative. This is an alias for 32-bit apps provided by Microsoft
which is a way into that directory. I'm not sure if there is an equivalent
for the registry.
—
Reply to this email directly or view it on GitHub.

---

Fiducia IT AG
Fiduciastraße 20
76227 Karlsruhe

Sitz der Gesellschaft: Karlsruhe
AG Mannheim HRB 100059

Vorsitzender des Aufsichtsrats: Peter Völker
Vorsitzender des Vorstands: Klaus-Peter Bruns
Vorstand: Jens-Olaf Bartels, Wolfgang Eckert, Carsten Pfläging, Jörg Staff

Umsatzsteuer-ID.Nr. DE143582320, http://www.fiducia.de

[bvb09michel]

Hello Michael,
the Windows version and the OS (32/64 bit) on Windows to determine is no
problem at all. We have our own software deployment and install any
software with its own install script.
I think most companies will make it so.

regards

Michael

Von: Michael Starks [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 06.10.2014 17:24
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

This also points out the need to have a customized ossec.conf per Windows
platform. Ideally, the installer should be able to detect which Windows
version and bitness it is being installed on, and deploy the correct
ossec.conf. The binaries and locations for each version may vary slightly
so this would ensure a correct and tailored default configuration per
environment.
—
Reply to this email directly or view it on GitHub.

---

Fiducia IT AG
Fiduciastraße 20
76227 Karlsruhe

Sitz der Gesellschaft: Karlsruhe
AG Mannheim HRB 100059

Vorsitzender des Aufsichtsrats: Peter Völker
Vorsitzender des Vorstands: Klaus-Peter Bruns
Vorstand: Jens-Olaf Bartels, Wolfgang Eckert, Carsten Pfläging, Jörg Staff

Umsatzsteuer-ID.Nr. DE143582320, http://www.fiducia.de

[bvb09michel]

We absolutely need a 64 bit Windows version. In the near future there will
be no more 32-bit Windows.

regards

Michael

Von: awiddersheim [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 06.10.2014 17:40
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

If we were able to make a x64 bit version of the agent would this still be
necessary? I'm trying to think of cases but am not coming up with any
right now.
—
Reply to this email directly or view it on GitHub.

---

Fiducia IT AG
Fiduciastraße 20
76227 Karlsruhe

Sitz der Gesellschaft: Karlsruhe
AG Mannheim HRB 100059

Vorsitzender des Aufsichtsrats: Peter Völker
Vorsitzender des Vorstands: Klaus-Peter Bruns
Vorstand: Jens-Olaf Bartels, Wolfgang Eckert, Carsten Pfläging, Jörg Staff

Umsatzsteuer-ID.Nr. DE143582320, http://www.fiducia.de

[awiddersheim]

@bvb09michel We got it and understand the request. Thanks. As I said before it is on my short list of things to try and do.

[bvb09michel]

Hi Michael

According to a recent study XP still has a market share of 23%.
Nevertheless, I would see it the same way that it is no longer respected
by ossec.

regards

Michael

Von: Michael Starks [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 06.10.2014 21:50
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

This one only exists on Vista+ and could be 32-bit or 64-bit:
C:\Users/Public/All Users/Microsoft/Windows/Start Menu/Startup, so if the
intent is to still support XP, then perhaps it's needed.
Then again, XP? Although the argument could be made that OSSEC is better
served on XP since it is more likely to be compromised, I am of the
opinion that the Project should not support EOL OSes, which have no more
security patches coming. People need motivation to move on and as security
professionals, we can help to provide that motivation.
—
Reply to this email directly or view it on GitHub.

---

Fiducia IT AG
Fiduciastraße 20
76227 Karlsruhe

Sitz der Gesellschaft: Karlsruhe
AG Mannheim HRB 100059

Vorsitzender des Aufsichtsrats: Peter Völker
Vorsitzender des Vorstands: Klaus-Peter Bruns
Vorstand: Jens-Olaf Bartels, Wolfgang Eckert, Carsten Pfläging, Jörg Staff

Umsatzsteuer-ID.Nr. DE143582320, http://www.fiducia.de

[jrossi]

x86_64-w64-mingw32-gcc is where to start :) with src/win32/make.sh (should be made into a real makefile but that is another issue).

http://stackoverflow.com/questions/5978722/compile-c-code-for-windows-64

This should be a simple process for anyone to play around with and see what they can do. @awiddersheim works on a lot of great things, but I am sure any help we can give him would be great.

Might be some issues that come up with 64bit builds but getting them built would be the start.

[awiddersheim]

Yeah, first step is to get things building. Second step is to use a real Makefile. I wanted to try and tackle this on my own in hopes of learning more but I may need help there. Last thing is tackling the installer.

[bvb09michel]

can anyone give me the current status? regards Michael

[awiddersheim]

I don't think anyone has started working on this. Asking for statuses isn't going to make this happen any faster either.

[123BLiN]

I use next workaround for x64 registry if this could help someone (I spent two days to find it :( ):
In ossec.conf on client:
<localfile> <log_format>full_command</log_format> <command>reg query "HKLM\SOFTWARE\my software" /s /f "Log Level" /reg:64</command> </localfile>
or simple /s for all subkeys
on server in local_rules.xml:
<rule id="100007" level="8"> <if_sid>530</if_sid> <match>ossec: output: 'reg query "HKLM\SOFTWARE\my software" /s /f "Log Level"</match> <check_diff /> <description>My software Log Level settings changed</description> </rule>
/reg:64 setting is not documented in Microsoft and I dont remeber where did I find it, it makes reg.exe to use x64 Registry view.

[bvb09michel]

Hi 123BLiN,
thanks for the workaround.

greetings Michael

Von: 123BLiN [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 29.04.2015 00:20
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

I use next workaround for x64 registry if this could help someone (I spent
two days to find it :( ):
In ossec.conf on client:

full_command
reg query "HKLM\SOFTWARE\my software" /s /f "Log Level" /reg:64

or simple /s for all subkeys
on server in local_rules.xml:

530
ossec: output: 'reg query "HKLM\SOFTWARE\my software" /s /f "Log Level"

My software Log Level settings changed

/reg:64 setting is not documented in Microsoft and I dont remeber where
did I find it, it make reg.exe to use x64 Registry view.
—
Reply to this email directly or view it on GitHub.

---

Fiducia IT AG
Fiduciastraße 20
76227 Karlsruhe

Sitz der Gesellschaft: Karlsruhe
AG Mannheim HRB 100059

Vorsitzender des Aufsichtsrats: Jürgen Brinkmann
Vorstand: Klaus-Peter Bruns (Vorsitzender), Claus-Dieter Toben (stv. Vorsitzender), Jens-Olaf Bartels,
Martin Beyer, Jörg Dreinhöfer, Wolfgang Eckert, Steffen Jentsch, Carsten Pfläging, Jörg Staff

Umsatzsteuer-ID.Nr. DE143582320, http://www.fiducia.de

[secnerd]

Hi,

just wondering if there is anything further I can help with - I see that it's tagged 'needs volunteers'. Also it should be noted that regardless of 64bit or 32bit agent there will still be a requirement to access redirected registry keys/system folders while Windows continues to support both architectures.

This suggests to me that this issue needs splitting into two - the first a bug, the current 32bit WIndows OSSEC agent is unable to access 64bit registry at the present time, the second is a feature request for a 64bit agent which would also need to be able to access the Windows 32 redirected registry keys and folders.

The reason for this is simple - the 32bit configuration and files can still be used as an attack vector in almost exactly the same way the 64bit 'native' keys and files can.

This is a fairly important issue as at the moment OSSEC running on 64bit Windows is somewhat handicapped - though I appreciate the above workarounds go some way to addressing the issue.

If I can help in testing or some other way please let me know - I'm not a coder but still managed to smash out #639 to attempt to address the issue though I know it's not an elegant solution.

Secnerd

[bvb09michel]

Hi Secnerd,
currently we have no need because we use the "Sysnative" workaround in
the ossec.conf for file accesses to system32 directory. This works just
fine.
To monitor the Registry, we are currently implementing no Hives, to a
32-bit process can't access.

greetings Michael

Von: secnerd [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 14.09.2015 23:36
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

Hi,
just wondering if there is anything further I can help with - I see that
it's tagged 'needs volunteers'. Also it should be noted that regardless of
64bit or 32bit agent there will still be a requirement to access
redirected registry keys/system folders while Windows continues to support
both architectures.
This suggests to me that this issue needs splitting into two - the first a
bug, the current 32bit WIndows OSSEC agent is unable to access 64bit
registry at the present time, the second is a feature request for a 64bit
agent which would also need to be able to access the Windows 32 redirected
registry keys and folders.
The reason for this is simple - the 32bit configuration and files can
still be used as an attack vector in almost exactly the same way the 64bit
'native' keys and files can.
This is a fairly important issue as at the moment OSSEC running on 64bit
Windows is somewhat handicapped - though I appreciate the above
workarounds go some way to addressing the issue.
If I can help in testing or some other way please let me know - I'm not a
coder but still managed to smash out #639 to attempt to address the issue
though I know it's not an elegant solution.
Secnerd
—
Reply to this email directly or view it on GitHub.

Fiducia & GAD IT AG | www.fiduciagad.de
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Hahnstr. 48, 60528 Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Claus-Dieter Toben (stv. Vorsitzender), Jens-Olaf Bartels,
Martin Beyer, Jörg Dreinhöfer, Wolfgang Eckert, Steffen Jentsch, Carsten Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann

[secnerd]

Hi Michael,

yep there's no issue with the file system using the sysnative workaround.

I'm not sure what you mean by 'implementing no hives'. The 32bit agent only
has access to the 32bit registry view, the native 64bit registry is in
accessible and contains potentially sensitive Windows and 64bit application
settings.

Cheers,

Secnerd

On 18 September 2015 at 14:46, bvb09michel [email protected] wrote:

Hi Secnerd,
currently we have no need because we use the "Sysnative" workaround in
the ossec.conf for file accesses to system32 directory. This works just
fine.
To monitor the Registry, we are currently implementing no Hives, to a
32-bit process can't access.

greetings Michael

Von: secnerd [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 14.09.2015 23:36
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

Hi,
just wondering if there is anything further I can help with - I see that
it's tagged 'needs volunteers'. Also it should be noted that regardless of
64bit or 32bit agent there will still be a requirement to access
redirected registry keys/system folders while Windows continues to support
both architectures.
This suggests to me that this issue needs splitting into two - the first a
bug, the current 32bit WIndows OSSEC agent is unable to access 64bit
registry at the present time, the second is a feature request for a 64bit
agent which would also need to be able to access the Windows 32 redirected
registry keys and folders.
The reason for this is simple - the 32bit configuration and files can
still be used as an attack vector in almost exactly the same way the 64bit
'native' keys and files can.
This is a fairly important issue as at the moment OSSEC running on 64bit
Windows is somewhat handicapped - though I appreciate the above
workarounds go some way to addressing the issue.
If I can help in testing or some other way please let me know - I'm not a
coder but still managed to smash out #639 to attempt to address the issue
though I know it's not an elegant solution.
Secnerd
—
Reply to this email directly or view it on GitHub.

Fiducia & GAD IT AG | www.fiduciagad.de
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Hahnstr. 48, 60528
Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Claus-Dieter Toben (stv.
Vorsitzender), Jens-Olaf Bartels,
Martin Beyer, Jörg Dreinhöfer, Wolfgang Eckert, Steffen Jentsch, Carsten
Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann

—
Reply to this email directly or view it on GitHub
#301 (comment).

[bvb09michel]

Hi Mark,
I have again tested all our Registry Keys from ossec.conf with both
system32\cmd.exe as well as with syswow64\cmd.exe (each as SYSTEM Account
with "reg query" commands on Windows Server 2008 R2 64 Bit).
When accessing the most hives you get the same output (because registry
redirection).
Only in some hives you get different outputs, for example
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run.
These hives I have to adjust the ossec.conf, for example
<log_format>full_command</log_format> reg query
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run" /s
/reg:64
We want to soon upgrade to version 2.8 and then we make the changes in
ossec.conf.
With the option /reg:64 the output is exactly the same with both cmd.exe.
I have traced with procmon the process ossec-agent.exe and you see a lot
of RegQueryValue entries on HKLM\Software\Microsoft ...
Nevertheless, would be a 64 bit version from ossec-agent for windows of
course the real thing. Especially since most of the software we use is 64
bit.

greetings Michael

Von: secnerd [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 19.09.2015 18:36
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

Hi Michael,

yep there's no issue with the file system using the sysnative workaround.

I'm not sure what you mean by 'implementing no hives'. The 32bit agent
only
has access to the 32bit registry view, the native 64bit registry is in
accessible and contains potentially sensitive Windows and 64bit
application
settings.

Cheers,

Mark

On 18 September 2015 at 14:46, bvb09michel [email protected]
wrote:

Hi Secnerd,
currently we have no need because we use the "Sysnative" workaround in
the ossec.conf for file accesses to system32 directory. This works just
fine.
To monitor the Registry, we are currently implementing no Hives, to a
32-bit process can't access.

greetings Michael

Von: secnerd [email protected]
An: ossec/ossec-hids [email protected],
Kopie: bvb09michel [email protected]
Datum: 14.09.2015 23:36
Betreff: Re: [ossec-hids] OSSEC agent on 64-bit Windows (#301)

Hi,
just wondering if there is anything further I can help with - I see that
it's tagged 'needs volunteers'. Also it should be noted that regardless
of
64bit or 32bit agent there will still be a requirement to access
redirected registry keys/system folders while Windows continues to
support
both architectures.
This suggests to me that this issue needs splitting into two - the first
a
bug, the current 32bit WIndows OSSEC agent is unable to access 64bit
registry at the present time, the second is a feature request for a
64bit
agent which would also need to be able to access the Windows 32
redirected
registry keys and folders.
The reason for this is simple - the 32bit configuration and files can
still be used as an attack vector in almost exactly the same way the
64bit
'native' keys and files can.
This is a fairly important issue as at the moment OSSEC running on 64bit
Windows is somewhat handicapped - though I appreciate the above
workarounds go some way to addressing the issue.
If I can help in testing or some other way please let me know - I'm not
a
coder but still managed to smash out #639 to attempt to address the
issue
though I know it's not an elegant solution.
Secnerd
—
Reply to this email directly or view it on GitHub.

Fiducia & GAD IT AG | www.fiduciagad.de
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Hahnstr. 48,
60528
Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Claus-Dieter Toben (stv.
Vorsitzender), Jens-Olaf Bartels,
Martin Beyer, Jörg Dreinhöfer, Wolfgang Eckert, Steffen Jentsch, Carsten
Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann

—
Reply to this email directly or view it on GitHub
#301 (comment).

—
Reply to this email directly or view it on GitHub.

Fiducia & GAD IT AG | www.fiduciagad.de
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Hahnstr. 48, 60528 Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Claus-Dieter Toben (stv. Vorsitzender), Jens-Olaf Bartels,
Martin Beyer, Jörg Dreinhöfer, Wolfgang Eckert, Steffen Jentsch, Carsten Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann

[gjyoung]

All,

Saw all the posts about this, thought I would throw up a worked over section of the file ossec.conf to help out, at least for the files section. This takes into consideration both directories, excludes deprecated features as far as I could tell. Includes files that may or may not be loaded as well, depending on if they were installed via programs and features, so there may still be a handful of errors depending on your environment. No warranty or guarantee expressed or implied!

It is not perfect but tons better than the stock 32 bit config file section:

<!-- Default files to be monitored – Win2012R2 only. -->
<directories check_all="yes">%WINDIR%/win.ini</directories>
<directories check_all="yes">%WINDIR%/system.ini</directories>
<directories check_all="yes">C:\autoexec.bat</directories>
<directories check_all="yes">C:\config.sys</directories>
<directories check_all="yes">C:\boot.ini</directories>
<directories check_all="yes">%WINDIR%/sysnative/at.exe</directories>
<directories check_all="yes">%WINDIR%/System32/at.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/attrib.exe</directories>
<directories check_all="yes">%WINDIR%/System32/attrib.exe</directories>
<directories check_all="yes">%WINDIR%/System32/cacls.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/cacls.exe</directories>
<directories check_all="yes">%WINDIR%/System32/eventcreate.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/eventcreate.exe</directories>
<directories check_all="yes">%WINDIR%/System32/ftp.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/ftp.exe</directories>
<directories check_all="yes">%WINDIR%/System32/net.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/net.exe</directories>
<directories check_all="yes">%WINDIR%/System32/net1.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/net1.exe</directories>
<directories check_all="yes">%WINDIR%/System32/netsh.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/netsh.exe</directories>
<directories check_all="yes">%WINDIR%/System32/reg.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/reg.exe</directories>
<directories check_all="yes">%WINDIR%/regedit.exe</directories>
<directories check_all="yes">%WINDIR%/System32/regedt32.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/regedt32.exe</directories>
<directories check_all="yes">%WINDIR%/System32/regsvr32.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/regsvr32.exe</directories>
<directories check_all="yes">%WINDIR%/System32/rshx32.dll</directories>
<directories check_all="yes">%WINDIR%/System32/rshx32.dll</directories>
<directories check_all="yes">%WINDIR%/System32/runas.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/runas.exe</directories>
<directories check_all="yes">%WINDIR%/System32/sc.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/sc.exe</directories>
<directories check_all="yes">%WINDIR%/System32/subst.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/subst.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/telnet.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/tftp.exe</directories>
<directories check_all="yes">%WINDIR%/sysnative/tlntsvr.exe</directories>
<directories check_all="yes">%WINDIR%/System32/drivers/etc</directories>
<directories check_all="yes" realtime="yes">C:\Documents and Settings/All Users/Start Menu/Programs/Startup</directories>
<directories check_all="yes" realtime="yes">C:\Users/Public/All Users/Microsoft/Windows/Start Menu/Startup</directories>
<ignore type="sregex">.log$|.htm$|.jpg$|.png$|.chm$|.pnf$|.evtx$</ignore>

[elvarb]

Ok we now have the solution from @gjyoung for the file monitoring, does the solution provided by @123BLiN for the registry work ?

Is the solution then to use the reg command to monitor the registry for 64bit hives and keep the basic registry check for the 32bit part or should everything be moved to using reg.exe?

[dalini]

are there any plans to establish a 64bit version of the windows agent? I also stumbled upon this telnet.exe not found issue and ended up here... the workarounds might be there but they are workarounds. It would be also great to consider improving the default settings to include the 64bit 'paths' in case the 64bit client might be further away...

[bvb09michel]

Hi Ives,
currently we do not intend to update the OSSEC client. In the long term
but I would obviously want a true 64-bit client.
Thanks in advance

Greetings Michael

Von: Ives Laaf [email protected]
An: ossec/ossec-hids [email protected]
Kopie: bvb09michel [email protected], Mention
[email protected]
Datum: 08.06.2016 14:54
Betreff: Re: [ossec/ossec-hids] OSSEC agent on 64-bit Windows
(#301)

are there any plans to establish a 64bit version of the windows agent? I
also stumbled upon this telnet.exe not found issue and ended up here...
the workarounds might be there but they are workarounds. It would be also
great to consider improving the default settings to include the 64bit
'paths' in case the 64bit client might be further away...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Fiducia & GAD IT AG | www.fiduciagad.de
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Hahnstr. 48, 60528 Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Claus-Dieter Toben (stv. Vorsitzender),
Jens-Olaf Bartels, Martin Beyer, Jörg Dreinhöfer, Wolfgang Eckert, Carsten Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann

[marcRBD]

There will be windows 2016 soon, i could have one version of it for testing
so i could give a try if there is a package.

[bvb09michel]

Yes very much. thank you

Von: marcRBD [email protected]
An: ossec/ossec-hids [email protected]
Kopie: bvb09michel [email protected], Mention
[email protected]
Datum: 14.10.2016 16:38
Betreff: Re: [ossec/ossec-hids] OSSEC agent on 64-bit Windows
(#301)

There will be windows 2016 soon, i could have one version of it for
testing
so i could give a try if there is a package.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Fiducia & GAD IT AG | www.fiduciagad.de
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Hahnstr. 48, 60528 Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Claus-Dieter Toben (stv. Vorsitzender),
Jens-Olaf Bartels, Martin Beyer, Jörg Dreinhöfer, Wolfgang Eckert, Carsten Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann

[marcRBD]

i could help testing if someone make packages ;)
i'm not good enough to create the ossec packages.
I test on windows 2016 this afternoon, and it doesn't work on a french version with any workaround i know (like the administrators group)

[ienliven]

still no 64bit windows agent.

[ddpbsd]

@ienliven Still no pull request.

[ddpbsd]

@andre-integritas Please test pull requet #1614

[elvarb]

Is any work being done regarding this issue?

[bvb09michel]

no, the topic is no longer being worked on Fiducia & GAD IT AG | www.fiduciagad.de AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Frankfurt a. M. | USt-IdNr. DE 143582320 Vorstand: Martin Beyer (Vorstandssprecher), Birgit Frohnhoff, Jörg Staff Vorsitzender des Aufsichtsrats: Jürgen Brinkmann Von: elvarb <[email protected]> An: ossec/ossec-hids <[email protected]> Kopie: bvb09michel <[email protected]>, Mention <[email protected]> Datum: 02.03.2020 14:00 Betreff: Re: [ossec/ossec-hids] OSSEC agent on 64-bit Windows (#301) Is any work being done regarding this issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[ddpbsd]

@elvarb I started working on it, but there wasn't any real interest.