What am I doing up?
It's Friday night / early Saturday morning.
I should be in bed, sleeping.
I was, but awoke full-on. Sometimes that happens.
I stumbled upon a new tool this morning.
This is what happens when your mind wanders into the Information Security sector of the Internet.
I was perusing my gmail email account and a LinkedIn group that I subscribe to pushed an email that looked interesting. One thing, actually one link lead to another and I found myself at a reverse engineering page that described a dissection of some malware.
Then, a reference to a reverse engineering tool I am not familiar with was mentioned.
That tool is PEStudio.
You can find it here.
http://www.winitor.com/
As a security tool it looks promising. I love good code. I love code that does what the author says it does. Have downloaded and will be investigating more in the AM over some coffee and breakfast.
- Ciao
Saturday, September 13, 2014
Saturday, May 3, 2014
Windows XP - Local Policies, Audit Policy - Setting SecEvent.evt Logs
Windows XP SP3
Local Policies, Audit Policy
Personal notes:
- Increase the log size to 4096 KB
- "Overwrite events as needed" - Radio Button
------------------------------------------------------------------------------------------
Audit account logon events
This security setting determines whether to audit each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. Account logon events are generated when a domain user account is authenticated on a domain
controller. The event is logged in the domain controller's security log. Logon events are generated when a local user is authenticated on a local computer. The event is logged in the local security log. Account logoff events are not generated.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when an account logon attempt succeeds. Failure audits generate an audit entry when an account logon attempt fails.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
If success auditing for account logon events is enabled on a domain controller, an entry is logged for each user who is validated against that domain controller, even though the user is actually logging on to a workstation that is joined to the domain.
Default: Success.
------------------------------------------------------------------------------------------
Audit account management
This security setting determines whether to audit each event of account management on a computer. Examples of account management events include:
A user account or group is created, changed, or deleted.
A user account is renamed, disabled, or enabled.
A password is set or changed.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when any account management event succeeds. Failure audits generate an audit entry when any account management event fails.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Default:
Success on domain controllers.
No auditing on member servers.
------------------------------------------------------------------------------------------
Audit directory service access
This security setting determines whether to audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.
By default, this value is set to no auditing in the Default Domain Controller Group Policy object (GPO), and it remains undefined for workstations and servers where it has no meaning.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a SACL specified. To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Note that you can set a SACL on an Active Directory object by using the Security tab in that object's Properties dialog box. This is the same as Audit object access, except that it applies only to Active Directory objects and not to file system and registry objects.
Default:
Success on domain controllers.
Undefined for a member computer.
------------------------------------------------------------------------------------------
Audit logon events
This security setting determines whether to audit each instance of a user logging on to or logging off from a computer.
Account logon events are generated on domain controllers for domain account activity and on local computers for local account activity. If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on the workstation or server, and they generate an account logon event on the domain controller. Additionally, interactive logons to a member server or workstation that use a domain account generate a logon event on the domain controller as the logon scripts and policies are retrieved when a user logs on. For more information about account logon events, see Audit account logon events.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit entry when a logon attempt fails.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Default: Success.
------------------------------------------------------------------------------------------
Audit object access
This security setting determines whether to audit the event of a user accessing an object—for example, a file, folder, registry key, printer, and so forth—that has its own system access control list (SACL) specified.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an object that has an appropriate SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an object that has a SACL specified.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Note that you can set a SACL on a file system object using the Security tab in that object's Properties dialog box.
Default: No auditing.
------------------------------------------------------------------------------------------
Audit policy change
This security setting determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies is successful. Failure audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies fails.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Default:
Success on domain controllers.
No auditing on member servers.
------------------------------------------------------------------------------------------
Audit privilege use
This security setting determines whether to audit each instance of a user exercising a user right.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit this type of event at all.
Success audits generate an audit entry when the exercise of a user right succeeds. Failure audits generate an audit entry when the exercise of a user right fails.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Default: No auditing.
Audits are not generated for use of the following user rights, even if success audits or failure audits are specified for Audit privilege use. Enabling auditing of these user rights tend to generate many events in the security log which may impede your computer's performance. To audit the following user rights, enable the FullPrivilegeAuditing registry key.
Bypass traverse checking
Debug programs
Create a token object
Replace process level token
Generate security audits
Back up files and directories
Restore files and directories
Caution:
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
------------------------------------------------------------------------------------------
Audit process tracking
This security setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate an audit entry when the process being tracked fails.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Default: No auditing
------------------------------------------------------------------------------------------
Audit system events
This security setting determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a system event is executed successfully. Failure audits generate an audit entry when a system event is attempted unsuccessfully.
To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.
Default:
Success on domain controllers.
No auditing on member servers.
------------------------------------------------------------------------------------------
Additional resources:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=%2Fcom.ibm.itcim.doc%2Ftcim85_install140.html
Configuring Windows XP auditing manually
Manual audit configuration should be performed on the audited system. In most cases, you must log in as Administrator to be able to adjust the audit settings.
Windows Security Log
------------------------------------------------------------------------------------------
In Microsoft® Windows®, auditing can be switched on and off for a number of event categories. Within each category, the auditing of successful and failed attempts can be controlled independently.
------------------------------------------------------------------------------------------
To turn on auditing of Windows XP events:
Run Local Security Policy snap-in from Start → All Programs → Administrative Tools or Control Panel → Administrative Tools.
In the snap-in tree select the Audit policy node (see Figure 17):
------------------------------------------------------------------------------------------
Sunday, June 3, 2012
HoNe - Running Process Cyber Attack Sensor
June 3, 2012 | Robert Cazares
I found this to be noteworthy of coming back to for further investigation in using this tool.
Hone is a unique open source tool developed by Pacific Northwest National Laboratory for correlating packets to processes to bridge the HOst-NEtwork divide.It is designed to determine which applications are communicating with external network, correlate packets to the responsible processes in Linux systems. Diagnose connections by adding process information.
Available for Linux kernels 2.6.32 and later.
Windows 7, Windows XP and a MacOS X version is planned.
Apr 11, 2012 | 05:06 PM
RICHLAND, Wash. - The good guys have a new, innovative tool to help them identify and understand cyber attacks.
Developed by a researcher at the Department of Energy’s Pacific Northwest National Laboratory, the new Hone cyber sensor determines how network activity on a computer is related to an application such as Internet Explorer or any running process. Finding these relationships enables cyber security experts to more quickly identify a potential problem and dissect how it works.
RICHLAND, Wash. - The good guys have a new, innovative tool to help them identify and understand cyber attacks.
Developed by a researcher at the Department of Energy’s Pacific Northwest National Laboratory, the new Hone cyber sensor determines how network activity on a computer is related to an application such as Internet Explorer or any running process. Finding these relationships enables cyber security experts to more quickly identify a potential problem and dissect how it works.
Full story is here:
http://www.darkreading.com/advanced-threats/167901091/security/news/232900169/pacific-northwest-national-laboratory-creates-new-sensor-to-stop-attackers-in-their-tracks.html
HoNe project at github can be found here:
https://github.com/HoneProject/Linux-Sensor#readme
Wednesday, April 13, 2011
Blindly restoring Windows XP screen resolution
Applies to Windows XP (any version)
Have you ever changed the screen resolution of your computer to where you have saved settings that your monitor cannot display? I have, several times. It's annoying at best to to have accidentally made a change and then not be able to see what you're doing.
Here are the steps to restore your display.
Please note that you have to be logged in.
If you need to blindly login to your account, I'll save those steps for a different post.
---------------------------------------------------
Take an educated guess and place the mouse cursor someplace on the desktop where you are not hovered over any icons or the toolbar.
The Monitor Setting dialog box will begin a countdown, "Reverting in n seconds".
Save your display settings.
And that should do it!
Have you ever changed the screen resolution of your computer to where you have saved settings that your monitor cannot display? I have, several times. It's annoying at best to to have accidentally made a change and then not be able to see what you're doing.
Here are the steps to restore your display.
Please note that you have to be logged in.
If you need to blindly login to your account, I'll save those steps for a different post.
---------------------------------------------------
Take an educated guess and
Click the Right Mouse button. - On your keyboard, press the
UP ARROW once, then press the ENTER key. - On your keyboard press the TAB
key four times. - On your keyboard, press the RIGHT ARROW
key four times. - On your keyboard press the TAB key once.
- Then press the
LEFT ARROW key four or five times - Then press the ENTER key.
The Monitor Setting dialog box will begin a countdown, "Reverting in n seconds".
Save your display settings.
And that should do it!
Tuesday, March 9, 2010
There's something amiss in China - Increased daily spam
OK, so for the past few weeks I have noticed a marked increase in spam in my primary email Spam folder. I have been deleting messages willy-nilly from the folder, as I usually do, when I walk through my daily email reading and composition routine.
Yesterday, I decided to let the spam pile up for a 24 hour period and take note of how many spam messages I have received. I don't like to pick on or lean in one direction or the other without having at least some metrics to go on, but out of 98 spam messages, 24 of those messages DID NOT have Chinese characters in the subject line.
Whup, OK, as I was typing this the message count JUST jumped to 102. By way of supposition, that's approximately 80% of the spam I have received in the past 24 hour period is coming from China.
Delving a little deeper I took a random check of the email headers, and yes, unless they're totally forged headers, I have to say, they do originate someplace in China. Where in China? Not important at this time. It's notable that they come from over the China border to here, at my gmail account in the United States.
So, what's happening here? Why the sudden spike in spam to my gmail account originating in China? Is there a mechanism I can implement to block ALL email from China from reaching my email account? I don't know anyone in China. I'm not expecting any email from China. Why can't I simply block all these messages? It's annoying at the very least and it is spam. I am going to keep my eye on this for a while, compile some data, see how it goes and maybe publish my results after 30 days or so. Is it worth it? I'll keep you posted.
- Robert Cazares
Yesterday, I decided to let the spam pile up for a 24 hour period and take note of how many spam messages I have received. I don't like to pick on or lean in one direction or the other without having at least some metrics to go on, but out of 98 spam messages, 24 of those messages DID NOT have Chinese characters in the subject line.
Whup, OK, as I was typing this the message count JUST jumped to 102. By way of supposition, that's approximately 80% of the spam I have received in the past 24 hour period is coming from China.
Delving a little deeper I took a random check of the email headers, and yes, unless they're totally forged headers, I have to say, they do originate someplace in China. Where in China? Not important at this time. It's notable that they come from over the China border to here, at my gmail account in the United States.
So, what's happening here? Why the sudden spike in spam to my gmail account originating in China? Is there a mechanism I can implement to block ALL email from China from reaching my email account? I don't know anyone in China. I'm not expecting any email from China. Why can't I simply block all these messages? It's annoying at the very least and it is spam. I am going to keep my eye on this for a while, compile some data, see how it goes and maybe publish my results after 30 days or so. Is it worth it? I'll keep you posted.
- Robert Cazares
Saturday, February 27, 2010
Wednesday, February 10, 2010
cnbc.com - San Antonio: New Cyber City
Airtime: Wed. Feb. 10 2010 | 12:17 PM ET
Discussing why San Antonio is key to cyber security, with NBC's Janet Shamlian and Dr. Greg White, colonel for the U.S. Air Force and Fred Ramirez, CNF Technologies.
http://www.cnbc.com/id/15840232?video=1410041474&play=1
Subscribe to:
Posts (Atom)