Timeline for Has exploitation been demonstrated against the fundamental constructs of the debugging process?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 15, 2021 at 21:29 | comment | added | goteguru | Ok. Thank you for the clarification. | |
| Jun 14, 2021 at 18:48 | comment | added | Margaret Bloom | Well, SeDebugPrivilege is a pretty strong privilege. But I was wrong, a debugger doesn't necessarily need it. So you are right, you can run a debugger with the same privilege of any other user program (including the malware). | |
| Jun 14, 2021 at 16:52 | comment | added | goteguru | @MargaretBloom I'm not a MS expert (linux is my choice), but to my understanding SeDebugPrivilege only grants debug right for other processes. If the debugger is run as full admin and has vulnerability, there is a trivial problem which OP is already aware of. I still can't see how a debug process could be exploited using SeDebugPrivilege. Would you clarify? | |
| Jun 13, 2021 at 15:15 | comment | added | Margaret Bloom |
A debugger can allow a malware to elevate privilege. The SeDebugPrivilege is own by the debugger (which often is run as full admin). If the debugger contains an exploit, the malware can make the debugger run arbitrary, privileged code. But this is dumb, a malware must work when not being debugged and should stop when it is, so relying on a debugger for LPE is just stupid.
|
|
| Jun 11, 2021 at 21:27 | history | edited | goteguru | CC BY-SA 4.0 |
deleted 602 characters in body
|
| Jun 11, 2021 at 21:15 | comment | added | goteguru | @J.Todd I think it's important to see debuggers and emulators operate differently. The methods in the paper you referenced won't work in case of debuggers. Other methods do. As a last resort defense line the idea is interesting (it wasn't clear to me). Still, I think building a honeypot would be more effective (and safer). I'm not sure how would you like to utilize ML methods for this purpose but I'm interested. I would gladly hear about it. You can find my email at my profile page. | |
| Jun 10, 2021 at 23:09 | comment | added | J.Todd | "Emulators and debuggers are not the same scenario at all." and by this, I meant the same scenario as in "both fundamentally make it possible for the attacker to notice the defense measure". My point was that I'm aware of the evasive behavior possible against debuggers and emulators, and it doesn't apply in this case because XYZ. | |
| Jun 10, 2021 at 23:05 | comment | added | J.Todd | You answer could be improved by removing the (I believe objectively wrong, both of which I addressed) opinions about why it shouldn't be done, and keep the last paragraph. I'd upvote the last paragraph, it's useful info. | |
| Jun 10, 2021 at 23:03 | comment | added | J.Todd | "Understanding the malware's inner mechanics and capabilities might need several run attempts. How does the debugger (software or human) know what steps are potentially dangerous?" Obfuscated or polymorphed malware is comparable to a story (or lots of short stories) with the same start and ending, just different ways of getting there. It's my hypothesis that machine learning can be leveraged to train against register and memory state changes over time to recognize what's really happening. | |
| Jun 10, 2021 at 23:01 | comment | added | J.Todd | "I think there is a fundamental problem with the "debugger approach": If we try to monitor the malware in the debugger -- which is certainly possible -- we are running the malicious code in the production environment using the host's libs, network and kernel. It's hardly a good idea." The point is, this is a last effort defense system. The attacker has already gotten past every previous layer of defense and is executing code on the target host. We're just making sure we identify the behavior signature so we can react rapidly. | |
| Jun 10, 2021 at 21:58 | history | answered | goteguru | CC BY-SA 4.0 |