Pseudocode for an internal scanner. Attempts to combat environmental manipulation through self-integrity checking, but a better mechanism may be needed.
Assumed this operates in a client/server model with the server offering messages to clients in a one-to-many or several-to-many relationship. Ulitmately, the server should be able to post a request (hash list, updated files) and the clients should pull the list, self check, perform the tests, and report back. The central system should them be able to generate reports based on the results.
INteresting reports might include which scanned successfully, which didn't report, any anomalies discovered. All hashes are passed back to central, so the tool could be used for forensic anomalies, known discovery of artifacts, discovery of similar artifacts within a defined threshhold, or compliance applications (similarity or direct matching). The insider threat model could be integrated by allowing the tracking of defined critical documents within reporting systems.
Client structure follows:
internal scanner
pull updates and signatures. check sig, decode to mem, load hashes
provide non-DOM driver to access disk filesystem - driver client bindings
provide access to memory - Volatility
check self integrity of all components, static files
Walk VAD and dump all processes/dll injects to disk
identify self in proc dump and validate hash vice known
dump registry hives in memory
extract registry values for known hostiles - regripper
for each proc/file
perform static hash scanning >> hashfile
perform context piecewise hashing >> cphfile
compile xml/soap response
encrypt, sign, report back to central
Needed tools:
http://code.google.com/p/pyssdeep/
http://www.py2exe.org/
https://www.volatilesystems.com/default/volatility
http://www.regripper.net/
http://ssdeep.sourceforge.net/
http://www.indigostar.com/perl2exe.htm
Monday, May 4, 2009
Friday, May 1, 2009
Opinion on SMTP Honeypots
honeyd is an infrastructure honeypot that refers to other services. it's a little heavy. If you are trying to emulate the Interweb on an open access point for research, it's great. For this, you want something more focused, either a honeytrapd type of service (dangerous on your border) or a full-time script running in its own process(s) to capture and handle load. Look at truman's (http://www.secureworks.com/research/tools/truman.html ) smtp script and consider reversing it's interally-focused intent to external. Add some support scripts for housekeeping and you should be good to go. Obviously, run in a dmz, with limited perms, on a box that is easily rebuilt and doesn't have other dependent, critical apps/processes. VM should be fine.
On Tue, Apr 28, 2009 at 12:28 PM, private investigation <xxx> wrote:
I tried to use honeyd but seems that honeyd cannot handle much of smtp request
On Tue, Apr 28, 2009 at 12:28 PM, private investigation <xxx> wrote:
I tried to use honeyd but seems that honeyd cannot handle much of smtp request
So You Thought You Were in Control of Your Friend List
Check this tool out! Facebook Controller:
http://my.opera.com/quakerdoomer/blog/2009/04/30/fbcontroller-facebook-controller-the-ultimate-facebook-controller-without-the-pa
Nice, using social media against you to subvert authentication controls, do recon, and manipulate data. Great POC!
http://my.opera.com/quakerdoomer/blog/2009/04/30/fbcontroller-facebook-controller-the-ultimate-facebook-controller-without-the-pa
Nice, using social media against you to subvert authentication controls, do recon, and manipulate data. Great POC!
SSH Command Monitoring
This was an interesting post from the secureshell list. Thanks Richard!
Hi "J",
you can do that with your unix/linux onboard tools. just attach strace
to the sshd process of the user you want to monitor:
strace -s 4096 -e trace=read -p PROCESS_ID
than have a look for the shell prompt (e.g.):
read(10, "\33]0;USERNAME@HOSTNAME:~\7"..., 16384) = 22
now you know that the FD (file handle) is 10 for the users ssh session terminal.
then you can do something like that:
strace -s 4096 -e trace=read -p 10417 2>&1 | grep -E '^read\(10,' |
grep -oE '".+"'
and you should get an output like:
"uname -a"
"\r\n"
"Linux HOSTNAME 2.6.29.1 #1 SMP Sat Apr 18 11:22:05 CEST 2009 i686
Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz GenuineIntel GNU/Linux\r\n"
"\33]0;USERNAME@HOSTNAME:~\7"
well, this will only work if you have root permission on the server
running sshd.
have fun,
richard
Hi "J",
you can do that with your unix/linux onboard tools. just attach strace
to the sshd process of the user you want to monitor:
strace -s 4096 -e trace=read -p PROCESS_ID
than have a look for the shell prompt (e.g.):
read(10, "\33]0;USERNAME@HOSTNAME:~\7".
now you know that the FD (file handle) is 10 for the users ssh session terminal.
then you can do something like that:
strace -s 4096 -e trace=read -p 10417 2>&1 | grep -E '^read\(10,' |
grep -oE '".+"'
and you should get an output like:
"uname -a"
"\r\n"
"Linux HOSTNAME 2.6.29.1 #1 SMP Sat Apr 18 11:22:05 CEST 2009 i686
Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz GenuineIntel GNU/Linux\r\n"
"\33]0;USERNAME@HOSTNAME:~\7"
well, this will only work if you have root permission on the server
running sshd.
have fun,
richard
Subscribe to:
Posts (Atom)