Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
Malware Analysis
Few questions regarding malware analysis lab - how to do it properly?
Message
<blockquote data-quote="struppigel" data-source="post: 984107" data-attributes="member: 86910"><p>1. Without analysing this sample: I can see that it is very old and a RAT. Those will generally not show much behaviour because they need a working C&C. Even two weeks can be too old for that. RATs always need that, and downloaders also need some working download locations. However it should be possible to see the network communication attempt, at least. Some samples have long sleeps and only run after some time. I sometimes let samples run over lunch and see what they were up to after my break.</p><p>Again, this is a generalized answer, I did not analyse the sample you gave. It is also possible there was an anti-reversing technique, that the sample is corrupt, buggy or needs some environmental factors (libraries, frameworks, other files, ...) that are not installed.</p><p>The best approach if it does not run is to do static in-depth analysis and debugging, see where it exits and what conditions were checked before that or what kind of exception is thrown.</p><p></p><p>2. To get deeper into that, check out this <a href="https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf" target="_blank">anti-reversing reference</a>. Do not only read it but build your own samples by writing assembly or C code (I personally used FASM), then disassemble/debug them with IDA. Defeating a technique is usually not that hard once you are able to recognize it, because most of the time all you gotta do is change a conditional check or a jump.</p><p>I started this way. I didn't work through the whole book, but it still helped a lot to recreate some of them.</p><p>There are also ways to harden your VM to defeat some VM detection techniques. Google them.</p><p></p><p>3. Don't be too hard on yourself. You just started, so naturally you will get lost because you won't recognize what is in front of you. I recommend to set small goals. Concentrate on fully analysing one (smaller) function instead of the whole malware code. I recommend the book Reversing: Secrets of Reverse Engineering. It is an old book but still relevant, because it will open your eyes to how you go about reversing in general. How you determine the calling convention. How you find out what the code does if you have nothing else (no strings etc).</p><p>Currently your biggest issue is probably recognizing common functions and algorithms. This only comes with experience. Use comments, variable and function renaming in IDA, to make the code better readable while you work through it</p><p>If real samples are too intimidating yet and you get lost too often, program smaller samples yourself. C or C++ are ideal candidates here. Disable compiler optimization, then compile the sample, then disassemble the sample and try to find and understand how each part of that code looks like in the disassembly.</p><p>Btw this is something I still do if there are new execution environments that I don't understand yet, e.g., Go binaries look a bit different than C and C++ applications, so you can help yourself to learn how they work by compiling your own program and disassembling it afterwards.</p><p>What you can also do is pick a sample that is referenced by a malware analysis article. Then try to find and understand the code pieces that the article mentions.</p><p></p><p>4. Generally stealers, downloaders and keyloggers tend to be easier. .NET assemblies, PyInstaller malware, Batch2EXE wrapped files also tend to be a bit more beginner friendly.</p><p>As a beginner I would keep my hands off of worms, viruses (file infectors) and ransomware. Not because they are hard, but because they are risky.</p><p>RATs are interesting, but not ideal to start with because they need a working C&C to see action in dynamic analysis.</p><p>Also, as a beginner, I would avoid Go, VB6 and Delphi binaries. C++ can be difficult if it uses a lot of object oriented code, but if not, it is much like C. Code written in assembly and C tends to be a bit more beginner friendly.</p><p></p><p>5. There is no generic approach to this. It highly depends on the sample. It depends on what you see in there and what your goal of the analysis is. In my daily work I mostly create detection signatures, so static analysis of file and memory dumps to find patterns for the signature is enough in 90% of the cases.</p><p>When I hunt and pick samples for blog articles, I spend a lot of time figuring out if the sample is already a known family or something new, so I research a lot and take detections names on VT, Intezer, yara rule matches, sandbox reports and typical strings as a basis for the research.</p><p>When I finally have a sample to analyze in-depth, most of the time is usually spent on deobfuscation (if the sample is obfuscated). For my latest sample this task took me two weeks (with breaks, though, it would have been one week or so if I did not have other tasks in between). Reading the code once it is deobfuscated, is not really the issue.</p><p>I fear I cannot help you with this question because it is too broad.</p><p>Watch some malware analysis Youtube channels like OALabs. There you can see how people approach specific samples.</p></blockquote><p></p>
[QUOTE="struppigel, post: 984107, member: 86910"] 1. Without analysing this sample: I can see that it is very old and a RAT. Those will generally not show much behaviour because they need a working C&C. Even two weeks can be too old for that. RATs always need that, and downloaders also need some working download locations. However it should be possible to see the network communication attempt, at least. Some samples have long sleeps and only run after some time. I sometimes let samples run over lunch and see what they were up to after my break. Again, this is a generalized answer, I did not analyse the sample you gave. It is also possible there was an anti-reversing technique, that the sample is corrupt, buggy or needs some environmental factors (libraries, frameworks, other files, ...) that are not installed. The best approach if it does not run is to do static in-depth analysis and debugging, see where it exits and what conditions were checked before that or what kind of exception is thrown. 2. To get deeper into that, check out this [URL='https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf']anti-reversing reference[/URL]. Do not only read it but build your own samples by writing assembly or C code (I personally used FASM), then disassemble/debug them with IDA. Defeating a technique is usually not that hard once you are able to recognize it, because most of the time all you gotta do is change a conditional check or a jump. I started this way. I didn't work through the whole book, but it still helped a lot to recreate some of them. There are also ways to harden your VM to defeat some VM detection techniques. Google them. 3. Don't be too hard on yourself. You just started, so naturally you will get lost because you won't recognize what is in front of you. I recommend to set small goals. Concentrate on fully analysing one (smaller) function instead of the whole malware code. I recommend the book Reversing: Secrets of Reverse Engineering. It is an old book but still relevant, because it will open your eyes to how you go about reversing in general. How you determine the calling convention. How you find out what the code does if you have nothing else (no strings etc). Currently your biggest issue is probably recognizing common functions and algorithms. This only comes with experience. Use comments, variable and function renaming in IDA, to make the code better readable while you work through it If real samples are too intimidating yet and you get lost too often, program smaller samples yourself. C or C++ are ideal candidates here. Disable compiler optimization, then compile the sample, then disassemble the sample and try to find and understand how each part of that code looks like in the disassembly. Btw this is something I still do if there are new execution environments that I don't understand yet, e.g., Go binaries look a bit different than C and C++ applications, so you can help yourself to learn how they work by compiling your own program and disassembling it afterwards. What you can also do is pick a sample that is referenced by a malware analysis article. Then try to find and understand the code pieces that the article mentions. 4. Generally stealers, downloaders and keyloggers tend to be easier. .NET assemblies, PyInstaller malware, Batch2EXE wrapped files also tend to be a bit more beginner friendly. As a beginner I would keep my hands off of worms, viruses (file infectors) and ransomware. Not because they are hard, but because they are risky. RATs are interesting, but not ideal to start with because they need a working C&C to see action in dynamic analysis. Also, as a beginner, I would avoid Go, VB6 and Delphi binaries. C++ can be difficult if it uses a lot of object oriented code, but if not, it is much like C. Code written in assembly and C tends to be a bit more beginner friendly. 5. There is no generic approach to this. It highly depends on the sample. It depends on what you see in there and what your goal of the analysis is. In my daily work I mostly create detection signatures, so static analysis of file and memory dumps to find patterns for the signature is enough in 90% of the cases. When I hunt and pick samples for blog articles, I spend a lot of time figuring out if the sample is already a known family or something new, so I research a lot and take detections names on VT, Intezer, yara rule matches, sandbox reports and typical strings as a basis for the research. When I finally have a sample to analyze in-depth, most of the time is usually spent on deobfuscation (if the sample is obfuscated). For my latest sample this task took me two weeks (with breaks, though, it would have been one week or so if I did not have other tasks in between). Reading the code once it is deobfuscated, is not really the issue. I fear I cannot help you with this question because it is too broad. Watch some malware analysis Youtube channels like OALabs. There you can see how people approach specific samples. [/QUOTE]
Insert quotes…
Verification
Post reply
Top
