The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics",
as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".
Tuesday, February 15, 2005
Incidents Question, part 1
I've been thinking about some of the stuff I've presented on, as well as talked to others about, and a thought came up...has anyone seen a compromised system with suspicious TaskScheduler jobs? Let me know...
2 comments:
Anonymous
said...
On Windows systems I've seen malware use the task scheduler to infect victims. Some SMB worms (like Gaobot variants) attempt to exploit weak usernames and passwords, copy their binaries over to an admin share once they succeed, and schedule a task to kick it off. The task is can be kept on the system to periodically start the malware in case it is killed.
On Unix systems, I've seen cronjobs to shovel an xterm back to the attacker. It's an old trick, and one of the first things a Unix incident responder should look for...
Excellent comment, Steve. However, as this blog is specific to Windows, I think that incident responders should include tools to check the contents of the Tasks directory, as well.
Specifically, as I pointed out in my book, a scheduled job that has it's .job file with the hidden bit set (ie, attrib +h) will not appear by default in 'dir', or the unmodified Windows Explorer, or in the Scheduled Tasks window.
2 comments:
On Windows systems I've seen malware use the task scheduler to infect victims. Some SMB worms (like Gaobot variants) attempt to exploit weak usernames and passwords, copy their binaries over to an admin share once they succeed, and schedule a task to kick it off. The task is can be kept on the system to periodically start the malware in case it is killed.
On Unix systems, I've seen cronjobs to shovel an xterm back to the attacker. It's an old trick, and one of the first things a Unix incident responder should look for...
Excellent comment, Steve. However, as this blog is specific to Windows, I think that incident responders should include tools to check the contents of the Tasks directory, as well.
Specifically, as I pointed out in my book, a scheduled job that has it's .job file with the hidden bit set (ie, attrib +h) will not appear by default in 'dir', or the unmodified Windows Explorer, or in the Scheduled Tasks window.
Post a Comment