Giter Site home page Giter Site logo

Ursnif Config Extraction about cape HOT 82 CLOSED

ctxis avatar ctxis commented on July 19, 2024
Ursnif Config Extraction

from cape.

Comments (82)

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo, this sounds good. Could you share some hashes with me and I'll have a look. Are you using the existing yara sig or a new updated one?

If the config data & key are easily had from API hooks we can make a package to capture them quite easily. If they use internal code then we will use the debugger. Please share with me your analysis so far and we can collaborate on the package?

Kev

from cape.

enzok avatar enzok commented on July 19, 2024

This is the Ursnif rule I'm using. We are interested in the code when it's injected into explorer.exe which I've only matched with CAPE Extraction. There are additional strings that would be good to match on, but they are in the .bss section which is decrypted during execution.

rule Ursnif
{
    meta:
        author = "enzo"
        description = "Ursnif final payload"
        cape_type = "Ursnif"
    strings:
        $a1 = {48 8B C4 53 55 56 57 41 54 41 55 41 56 41 57 48 83 EC 48 48 8B 51 30 48 8B F9 48 85 D2 48 89 50 10}
        $a2 = {8B 70 EC 33 70 F8 33 70 08 33 30 83 C0 04 33 F1 81 F6 B9 79 37 9E C1 C6 0B 89 70 08 41 81 F9 84 00 00 00 72 DB}
        $b1 = "Tape Device" fullword
    condition:
        uint16(0) == 0x5A4D and (all of ($a*)) and (not $b1)
}

I think the debugger will be needed, but you can verify.

Dropper/Loader Hash

  • 2a3d5d175b57c0e1ea1a4683f7956d70091fa9fcb75b2b1b0fab4cb8424aedb0

Final Payload Hash (injected into explorer.exe in my case)

  • 965815c05bdf1672915a8420b6be86ddbc4ce1066c06f374f5ba37c31086ff84

I can share the .idb file with you if you have IDA. Let me know how you would like to collaborate.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Thanks for the hashes and the sig - this sample has been really useful as it has helped me find a couple of issues with the Injection package which should of course have been able to dump the payloads injected into explorer.

I've fixed the package now and pushed the updates, as well as updating the signature to detect both the 32-bit and 64-bit DLLs which are injected into explorer. You can see the results on the public instance: https://cape.contextis.com/analysis/3060.

So next let's look at the config - sharing the .idb file sounds good to me. You could email it to me if it's not too big - do you have my address?

from cape.

enzok avatar enzok commented on July 19, 2024

I don't have your address.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

It's my github username at gmail

from cape.

enzok avatar enzok commented on July 19, 2024

After merging the Ursnif commits I get the following errors:

OSError: [Errno 2] No such file or directory: '/opt/cuckoo/storage/analyses/4570/files' 2017-10-30 15:31:44,538 [modules.processing.suricata] WARNING: Suricata returned a Exit Value Other than Zero 30/10/2017 -- 15:31:44 - <Error> - [ERRCODE: SC_ERR_LOGDIR_CMDLINE(117)] - The logging directory "/opt/cuckoo/storage/analyses/4570/logs" supplied at the commandline (-l /opt/cuckoo/storage/analyses/4570/logs) doesn't exist. Shutting down the engine.

I think the tasks are just timing out and shutting down without any reporting. This then leads to processing errors obviously.

I reverted and everything went back to normal.

Also, I'm sending you the idb.

Cheers and thanks.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Oh dear that isn't good. Is it the commit with the new Injection DLLs? Perhaps they are causing analysis to fail. Do you think you could run a test to see if this is the case?

Thanks for the idb - I'm looking into it now.

Cheers

from cape.

enzok avatar enzok commented on July 19, 2024

yes it's the new DLLs, the other commits are fine
analysis is failing, tried on 32-bit and 64-bit VMs

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hmm weird - would you mind checking to see if there is anything obvious in the analysis log? Is it just the Injection package? I can't reproduce this unfortunately.

from cape.

enzok avatar enzok commented on July 19, 2024

I reinstalled the updated DLLs and everything seems to work now. Must have been a bad fetch or something.

from cape.

marirs avatar marirs commented on July 19, 2024

I still have the problem, not sure if its bad fetch - how did you reinstall the dlls? what was the method? you still made a fetch right?

from cape.

enzok avatar enzok commented on July 19, 2024

yes I did a fetch and merge, verified that the md5s matched when I pushed to my server. Now it seems to work.

However, I did have one failure during extraction:

2017-10-31 15:08:45,000 [root] INFO: Date set to: 10-31-17, time set to: 19:08:45 2017-10-31 15:08:45,015 [root] INFO: Analyzer:prepare: DEFAULT_DLL was None, DEFAULT_DLL_64 was None 2017-10-31 15:08:45,015 [root] INFO: Analyzer:prepare: DEFAULT_DLL set to None, DEFAULT_DLL_64 set to None 2017-10-31 15:08:45,000 [root] INFO: Date set to: 10-31-17, time set to: 19:08:45 2017-10-31 15:08:45,000 [root] INFO: Analyzer:prepare: DEFAULT_DLL was None, DEFAULT_DLL_64 was None 2017-10-31 15:08:45,000 [root] INFO: Analyzer:prepare: DEFAULT_DLL set to None, DEFAULT_DLL_64 set to None 2017-10-31 15:08:45,000 [root] DEBUG: Starting analyzer from: C:\utitlmw 2017-10-31 15:08:45,000 [root] DEBUG: Storing results at: C:\nQubPqbtQ 2017-10-31 15:08:45,015 [root] DEBUG: Pipe server name: \\.\PIPE\YdKXGF 2017-10-31 15:08:45,015 [root] INFO: Analysis package "Extraction" has been specified. 2017-10-31 15:08:45,155 [root] DEBUG: Started auxiliary module Auxfile 2017-10-31 15:08:45,155 [root] DEBUG: Started auxiliary module Browser 2017-10-31 15:08:45,155 [modules.auxiliary.digisig] DEBUG: Checking for a digitial signature. 2017-10-31 15:08:45,250 [modules.auxiliary.digisig] DEBUG: File is not signed. 2017-10-31 15:08:45,250 [modules.auxiliary.digisig] INFO: Uploading signature results to aux/DigiSig.json 2017-10-31 15:08:45,250 [root] DEBUG: Started auxiliary module DigiSig 2017-10-31 15:08:45,250 [root] DEBUG: Started auxiliary module Disguise 2017-10-31 15:08:45,265 [root] DEBUG: Started auxiliary module Human 2017-10-31 15:08:45,265 [root] DEBUG: Started auxiliary module Screenshots 2017-10-31 15:08:45,265 [root] DEBUG: Started auxiliary module Usage 2017-10-31 15:08:45,265 [root] INFO: Analyzer:run: DEFAULT_DLL set to Extraction.dll from package modules.packages.Extraction 2017-10-31 15:08:45,265 [root] INFO: Analyzer:run: DEFAULT_DLL_64 set to Extraction_x64.dll from package modules.packages.Extraction 2017-10-31 15:08:45,280 [lib.api.process] INFO: Successfully executed process from path "C:\Users\benji\AppData\Local\Temp\kronc.mdf" with arguments "" with pid 1336 2017-10-31 15:08:45,280 [lib.api.process] INFO: DLL to inject is dll\Extraction.dll 2017-10-31 15:08:45,280 [lib.api.process] DEBUG: Using QueueUserAPC injection. 2017-10-31 15:08:45,296 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 1336 2017-10-31 15:08:47,296 [lib.api.process] INFO: Successfully resumed process with pid 1336 2017-10-31 15:08:47,296 [root] INFO: Added new process to list with pid: 1336 2017-10-31 15:08:47,312 [root] DEBUG: WoW64 detected: 64-bit ntdll base: 0x774f0000, KiUserExceptionDispatcher: 0x7753bc8a, NtSetContextThread: 0x7753d260, Wow64PrepareForException: 0x74f3e4a0 2017-10-31 15:08:47,312 [root] DEBUG: WoW64 workaround: KiUserExceptionDispatcher hook installed at: 0x160000 2017-10-31 15:08:47,312 [root] DEBUG: CAPE initialised (32-bit). 2017-10-31 15:08:47,328 [root] INFO: Cuckoomon successfully loaded in process with pid 1336. 2017-10-31 15:08:47,328 [root] DEBUG: NtAllocateVirtualMemory hook, BaseAddress:0x310000, RegionSize: 0x63000. 2017-10-31 15:08:47,328 [root] DEBUG: SetInitialWriteBreakpoint: AllocationBase: 0x310000, AllocationSize: 0x63000, ThreadId: 0x778 2017-10-31 15:08:47,328 [root] DEBUG: SetDebugRegister: Setting breakpoint 0 hThread=0xc4, Size=0x2, Address=0x310000 and Type=0x1. Address:0x310000, RegionSize: 0x63000. 2017-10-31 15:08:47,328 [root] DEBUG: SetInitialWriteBreakpoint: AllocationBase: 0x310000, AllocationSize: 0x63000, ThreadId: 0x778 2017-10-31 15:08:47,328 [root] DEBUG: SetDebugRegister: Setting breakpoint 0 hThread=0xc4, Size=0x2, Address=0x310000 and Type=0x1.
Log just ends here. So maybe there is still some instability here.

Here's the sample I was having issues with yesterday. Seems to process fine now.

https://www.virustotal.com/en/file/18a10852b14df97b69243b38b23a573cc89d7629115ee0fefbbd66a00078ea4f/analysis/

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Thanks for the sample hash, let me look into it and see if i can work out what's going on.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I now suspect the problem may have been due to bugs introduced into the processing module. I've tried to clean up the code in this and submitCAPE reporting module as suggested by marirs, hopefully the most recent push will clear up the problems. Please let me know how you go, thanks.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo, just to give you an update - I have looked at your IDB (thanks for that) and I think you are right about using the debugger. The other alternative which I looked at was to do the decryption and parsing of the BSS section in a config parsing script in the processing phase. It looked like the main decryption algorithm was quite simple and straightforward to reimplement in Python. But there are a couple of functions, quite a few inputs (like operations on the version strings in the binary) so in the end this looks more complicated than just sticking a breakpoint on the decryption function and dumping its output and key.

So I have been looking at creating a debugger package. Since fixing the Injection package it looks like there is a 32 and 64-bit version of the final payload so we'll need to cover both. But the problem I've hit is that I'm finding the behaviour of the sample tricky to reproduce. On one of my systems (64-bit) explorer spawns a final process wmpnscfg.exe which it hollows with the payload. But on other of my systems this doesn't happen. I suspect it's something to do with the state of the vm, I noticed it looking at Firefox's prefs.js which was missing on one system. I've set Firefox up properly now but still I can't get that final process to spawn. Any ideas on what it needs to get there?

from cape.

enzok avatar enzok commented on July 19, 2024

Is the issue with just the 64-bit variant?

from cape.

enzok avatar enzok commented on July 19, 2024

On my VMs (Win 7 SP1 64-bit) an svchost.exe process injects into explorer.exe (this would be the equivalent CAPE process dump that I used for the 32-bit binary that I analyzed.) Are you saying that explorer.exe goes one step further with wmpnscfg.exe?

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Yeah exactly - explorer goes one further and spawns a new process. I suspect that it's in this final process that it goes down the route of decryptinh the .bss and doing its comms via the flag it checks for in DllMain - I haven't checked this for sure though. If the .bss is decrypted any time prior to this then we don't need it, but I think it's likely to only execute that path (and thus trip the breakpoint) in the final process.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I just tried on an xp vm, and it doesn't get any further than explorer either...

from cape.

enzok avatar enzok commented on July 19, 2024

Is it possible that the final process doesn't trigger until it properly communicates with it's C2? Although, I have samples where comms are occurring from explorer.exe (32-bit); it would have had to have decoded the .bss section to do so.

MD5: a3b82142eebd5d3650563b05ebb1be1ac546436d166f1a70b65c56011db5ffc7

from cape.

enzok avatar enzok commented on July 19, 2024

sha256 not MD5...

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

You're right if the comms is happening then it must be decoded - unfortunately I haven't had any do comms - it's probably quite particular about the setup. Let me have a go at setting up the breakpoint and we'll see if we can get it to hit.

from cape.

enzok avatar enzok commented on July 19, 2024

I added a text file to the dropbox share. It contains analysis notes from a sample I reversed back in 2015. I don't have the .idb file unfortunately. Something to note. There is a compressed(maybe encrypted) config data block with initial values. Finding this would be ideal as it contains the serpent encryption key for comms along with other info. I know I pulled it from memory, but don't remember what code generated it. I don't know if the mechanism has changed in newer versions. I haven't had a chance to compare the notes to see if they still apply fully to newer samples. It shouldn't be too different, so hopefully something in the notes helps.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Thanks - I'll have a look at this and hopefully spend a bit more time analysing some samples to get to the bottom of it.

from cape.

enzok avatar enzok commented on July 19, 2024

Any luck with this? I haven't had time to look at it too much.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo, I'm sorry I've been slack on this, I've been caught up in some other work. I'll get back on the case and do some tests to see whether I can catch the .bss decryption with a breakpoint.

from cape.

enzok avatar enzok commented on July 19, 2024

No worries. I appreciate any time you have. Thanks.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo - good news. I've created a debugger package for Ursnif, the first challenge was as discussed previously, that most of the time the samples don't seem to get to the final process, and I discovered that unfortunately this means the .bss section isn't decrypted. So I decided to manipulate the execution flow in the debugger to force it to decrypt this section by manipulating a test it performs just prior to decrypting. This works nicely and allows the module to dumped with the .bss section decrypted, ready for config parsing.

I haven't quite completed all the bits yet, I've only just got it working for 64-bit, but I'll try and wrap up the package and push it tomorrow all being well. In the meantime if you want to have a look at an example, check the payload in the following job on the public instance:

https://cape.contextis.com/analysis/3432

The .bss is in the clear - next step, parsing the config! Cheers

from cape.

enzok avatar enzok commented on July 19, 2024

That's great. Thanks!

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo, I've just pushed the new Ursnif package to github, and have run a couple of demo samples on our public instance to demonstrate:

https://cape.contextis.com/analysis/3481
https://cape.contextis.com/analysis/3487

To work in an automated way, the package depends upon having been triggered by the Injection package as this gets the payload DLL which contains the relevant decryption code and is used to set the breakpoint in the Ursnif job. So submitting samples with no options will result in Extraction and Injection being triggered, and the payload from the Injection job triggers the Ursnif job. Simple!

It's not complete of course without a parsing script, I'll have a look at that next. For the moment the config can be read from the payload binary in the decrypted .bss section. It's handy that all those strings tie up nicely with cross-references in IDA greatly helping with analysis.

Do you have any particular config items in mind to be displayed/downloaded in the web interface? There's quite a lot in there!

from cape.

enzok avatar enzok commented on July 19, 2024

Nicely done. I'll merge the new commits and give it a go. I'll take a look and provide more feedback. Thanks!

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo, I've just pushed a basic initial config parser, having cherry-picked some obvious entries from the configuration strings as examples. Hopefully this will be a basis we can refine to the finished article.

I've run it on three samples on our public instance:

https://cape.contextis.com/analysis/3481
https://cape.contextis.com/analysis/3487
https://cape.contextis.com/analysis/3511

To get to the config and payload with these links, follow first the link to the Injection job, then from there the link to the Ursnif job.

Let me know what you think.

from cape.

enzok avatar enzok commented on July 19, 2024

I looked over your config examples. The "C2 URL" you have labeled is actually the document used for DGA. I think the sample needs to run some more to get the actual config. I'll email you a more comprehensive config as soon as I can get one dumped.

Also, here's another sample that doesn't seem to trigger the yara rule. Not sure what changed.

e571be01ba923680e39064b3ce1ad342

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Thanks for the sample - I did wonder if there might be more to it. I've not looked too deeply beyond getting the bss. I've got a few days leave next week but will back on it on Wednesday.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo, so I finally found some time to dig into Ursnif a bit more and find that pesky config. I've just published an new version which comprises an updated monitor which decrypts the .bss section as well as dumping the config blob. This is then parsed, but the parser could use a bit more refining and with proper labelling of the appropriate config items. Let me know if this is something you can help with.

There are a few recent examples up on the public version:

https://cape.contextis.com/analysis/4112
https://cape.contextis.com/analysis/4113
https://cape.contextis.com/analysis/4114

As you can see, some of the config items don't have names yet (Value1, 2, 3 etc). Also it probably doesn't work with older samples yet but I thought I'd focus on recent ones first, then hopefully expand it as necessary to cover older ones. It's been a good package to work on as it's helped me nail a few issues with the CAPE debugger, notably coping properly with breakpoints across multiple threads.

Anyway, let me know what you think.

from cape.

enzok avatar enzok commented on July 19, 2024

This is awesome. I'll take a look at this, and also see if I can help you with the config labels.

from cape.

enzok avatar enzok commented on July 19, 2024

Value3 is the encryption key.

from cape.

enzok avatar enzok commented on July 19, 2024

Value10 is the botnet ID - 1000 series = DGA, 2000 series = Fluxxy Fast Flux Hosting
Alternate Download URLs = 64bit DLL domains
Download URLS = 32bit DLL domains
domain suffixes = DGA TLDs

from cape.

enzok avatar enzok commented on July 19, 2024

The date string from the .bss decryption function (used to calculate the key) is the version compilation date. It's also found in the .rdata section at the Export directory RVA.

Finally the bot version is found in the initial C2 comms string;

soft=%u&version=%u&user=%08x%08x%08x%08x&server=%u&id=%u&crc=%x

ex. version=216951 (0x34F77)

It's hard coded in the function as far as I can tell, and not in the config. I could be wrong though.

from cape.

enzok avatar enzok commented on July 19, 2024

value8 = knockertimeout
value2 = server
value7 = sendtimeout
value6 = tasktimeout
value5 = configtimeout
value4 = configfailtimeout
Hex Value = dga_crc
value1 = dga_season
value9 = bctimeout

There are a few values that I expected to see, but maybe they weren't parsed. If I can look at the dumped config buffer I can verify those.

from cape.

enzok avatar enzok commented on July 19, 2024

these values are all for task 4112

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Awesome thanks for those - I've updated the parser with these labels and reprocessed the example jobs so you can see. I can share the raw blob if you like (the file is saved in the storage folder for the job on the server) but in the case of 4112 there are only 20 items, and 11 for the other two. The first dword of the blob holds the number of items + 1 (one seems to be an 'end' pointer). The blob can be made downloadable (this is governed by the 'append_file' flag in the processing module) if it will make it easier during testing.

from cape.

enzok avatar enzok commented on July 19, 2024

Not getting the config. Following errors in log.

2018-01-29 14:11:56,773 [modules.processing.CAPE] INFO: CAPE: Imported malwareconfig.com parser Ursnif
2018-01-29 14:11:56,783 [modules.processing.CAPE] ERROR: CAPE: malwareconfig parsing error with Ursnif: unpack requires a string argument of length 4
2018-01-29 14:11:59,565 [modules.processing.CAPE] INFO: CAPE: Imported malwareconfig.com parser Ursnif
2018-01-29 14:11:59,574 [modules.processing.CAPE] ERROR: CAPE: malwareconfig parsing error with Ursnif: unpack requires a string argument of length 4

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

from cape.

enzok avatar enzok commented on July 19, 2024

Sample from task 4112
I'm running others and will try 64-bit also.

Thanks.

from cape.

enzok avatar enzok commented on July 19, 2024

Same results with a couple of other samples. The 64-bit samples are causing the VMs to shutdown unexpectedly. Here is the analysis log. Hope it helps.

2018-01-29 15:59:10,405 [root] INFO: Analyzer: DLL set to Extraction.dll from package modules.packages.Extraction
2018-01-29 15:59:10,405 [root] INFO: Analyzer: Package modules.packages.Extraction does not specify a DLL_64 option
2018-01-29 15:59:10,421 [lib.api.process] INFO: Successfully executed process from path "C:\Users\barry\AppData\Local\Temp\10348995c8c513d9b92b15272d37055f9488d449f60d0dca976e041e411f55e2.exe" with arguments "" with pid 1344
2018-01-29 15:59:10,421 [lib.api.process] INFO: DLL to inject is dll\NOpqySl.dll
2018-01-29 15:59:10,421 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 15:59:10,467 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 1344
2018-01-29 15:59:12,500 [lib.api.process] INFO: Successfully resumed process with pid 1344
2018-01-29 15:59:12,500 [root] INFO: Added new process to list with pid: 1344
2018-01-29 15:59:12,592 [root] DEBUG: WoW64 detected: 64-bit ntdll base: 0x77150000, KiUserExceptionDispatcher: 0x771a121a, NtSetContextThread: 0x771a27e0, Wow64PrepareForException: 0x7379e340
2018-01-29 15:59:12,592 [root] DEBUG: WoW64 workaround: KiUserExceptionDispatcher hook installed at: 0x270000
2018-01-29 15:59:12,592 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 15:59:12,608 [root] INFO: Cuckoomon successfully loaded in process with pid 1344.
2018-01-29 15:59:14,467 [root] DEBUG: NtAllocateVirtualMemory hook, BaseAddress:0x1d90000, RegionSize: 0x5c000.
2018-01-29 15:59:14,467 [root] DEBUG: SetInitialWriteBreakpoint: AllocationBase: 0x1d90000, AllocationSize: 0x5c000, ThreadId: 0x8c8
2018-01-29 15:59:14,467 [root] DEBUG: SetDebugRegister: Setting breakpoint 0 hThread=0xac, Size=0x2, Address=0x1d90000 and Type=0x1.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

from cape.

enzok avatar enzok commented on July 19, 2024

Does this help?

2018-01-29 15:23:22,000 [root] INFO: Date set to: 01-29-18, time set to: 20:23:22
2018-01-29 15:23:22,030 [root] DEBUG: Starting analyzer from: C:\xdpsrwa
2018-01-29 15:23:22,030 [root] DEBUG: Storing results at: C:\LzinVNHcJT
2018-01-29 15:23:22,030 [root] DEBUG: Pipe server name: \\.\PIPE\tNkBIL
2018-01-29 15:23:22,030 [root] INFO: Analysis package "Injection" has been specified.
2018-01-29 15:23:22,171 [root] DEBUG: Started auxiliary module Auxfile
2018-01-29 15:23:22,171 [root] DEBUG: Started auxiliary module Browser
2018-01-29 15:23:22,171 [modules.auxiliary.digisig] DEBUG: Checking for a digitial signature.
2018-01-29 15:23:22,296 [modules.auxiliary.digisig] DEBUG: File is not signed.
2018-01-29 15:23:22,296 [modules.auxiliary.digisig] INFO: Uploading signature results to aux/DigiSig.json
2018-01-29 15:23:22,296 [root] DEBUG: Started auxiliary module DigiSig
2018-01-29 15:23:22,312 [root] DEBUG: Started auxiliary module Disguise
2018-01-29 15:23:22,312 [root] DEBUG: Started auxiliary module Human
2018-01-29 15:23:22,328 [root] DEBUG: Started auxiliary module Screenshots
2018-01-29 15:23:22,328 [root] DEBUG: Started auxiliary module Usage
2018-01-29 15:23:22,328 [root] INFO: Analyzer: DLL set to Injection.dll from package modules.packages.Injection
2018-01-29 15:23:22,328 [root] INFO: Analyzer: DLL_64 set to Injection_x64.dll from package modules.packages.Injection
2018-01-29 15:23:22,375 [lib.api.process] INFO: Successfully executed process from path "C:\Users\carlos\AppData\Local\Temp\1b77701f7002213d604e45eab16e2b7f.exe" with arguments "" with pid 2396
2018-01-29 15:23:22,375 [lib.api.process] INFO: DLL to inject is dll\eAZjhii.dll
2018-01-29 15:23:22,375 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 15:23:22,405 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 2396
2018-01-29 15:23:24,405 [lib.api.process] INFO: Successfully resumed process with pid 2396
2018-01-29 15:23:24,405 [root] INFO: Added new process to list with pid: 2396
2018-01-29 15:23:24,483 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 15:23:24,483 [root] INFO: Cuckoomon successfully loaded in process with pid 2396.
2018-01-29 15:23:25,265 [root] INFO: Disabling sleep skipping.
2018-01-29 15:23:34,546 [root] DEBUG: GetInjectionInfo: Failed to find InjectionInfoList.
2018-01-29 15:23:34,546 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x8a1050 for process 2396.
2018-01-29 15:23:34,546 [root] DEBUG: NtOpenProcess: Injection info created for pid 2396.
2018-01-29 15:23:34,546 [root] DEBUG: NtOpenProcess: Image base for process 2396 (handle 0x140): 0x00400000.
2018-01-29 15:23:38,092 [root] DEBUG: NtMapViewOfSection hook: Added section view with handle 0x164 and local view 0x37f0000 to global list.
2018-01-29 15:23:38,092 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x8a6ef0 for process 1916.
2018-01-29 15:23:38,092 [root] DEBUG: NtOpenProcess: Injection info created for pid 1916.
2018-01-29 15:23:38,108 [root] DEBUG: Error 5 (0x5) - get_process_image_base: ReadProcessMemory failed to read from 0x7FFDF000: Access is denied.
2018-01-29 15:23:38,108 [root] DEBUG: NtOpenProcess: Error obtaining target process image base for process 1916 (handle 0x144).
2018-01-29 15:23:38,125 [root] DEBUG: NtResumeThread hook: CurrentInjectionInfo 0x8a1050 (pid 2396).
2018-01-29 15:23:38,125 [root] DEBUG: DumpSectionViewsForPid: no shared section views found for pid 2396.
2018-01-29 15:23:39,062 [root] INFO: Announced 32-bit process name: cmd.exe pid: 552
2018-01-29 15:23:39,062 [lib.api.process] INFO: DLL to inject is dll\eAZjhii.dll
2018-01-29 15:23:39,062 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 15:23:39,078 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 552
2018-01-29 15:23:39,078 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x8be4a0 for process 552.
2018-01-29 15:23:39,078 [root] DEBUG: CreateProcessInternal hook: using lpCommandLine: "C:\Users\carlos\AppData\Local\Temp\40E2\9851.bat" "C:\Users\carlos\AppData\Roaming\MICROS~1\Comrusic\ELSCroxy.exe" "C:\Users\carlos\AppData\Local\Temp\1B7770~1.EXE".
2018-01-29 15:23:39,078 [root] DEBUG: CreateProcessInternal hook: Injection info set for new process 552, ImageBase: 0x4a2b0000
2018-01-29 15:23:39,092 [root] INFO: Notified of termination of process with pid 2396.
2018-01-29 15:23:39,108 [root] INFO: Disabling sleep skipping.
2018-01-29 15:23:39,108 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 15:23:39,125 [root] INFO: Added new process to list with pid: 552
2018-01-29 15:23:39,125 [root] INFO: Cuckoomon successfully loaded in process with pid 552.
2018-01-29 15:23:39,155 [root] DEBUG: GetInjectionInfo: Failed to find InjectionInfoList.
2018-01-29 15:23:39,171 [root] DEBUG: NtMapViewOfSection hook: Added section view with handle 0xd0 and local view 0x2d50000 to global list.
2018-01-29 15:23:39,171 [root] INFO: Announced 32-bit process name: cmd.exe pid: 3940
2018-01-29 15:23:39,171 [lib.api.process] INFO: DLL to inject is dll\eAZjhii.dll
2018-01-29 15:23:39,171 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 15:23:39,233 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 3940
2018-01-29 15:23:39,233 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x317d80 for process 3940.
2018-01-29 15:23:39,265 [root] DEBUG: CreateProcessInternal hook: Injection info set for new process 3940, ImageBase: 0x4a2b0000
2018-01-29 15:23:39,265 [root] INFO: Disabling sleep skipping.
2018-01-29 15:23:39,280 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 15:23:39,296 [root] INFO: Added new process to list with pid: 3940
2018-01-29 15:23:39,296 [root] INFO: Cuckoomon successfully loaded in process with pid 3940.
2018-01-29 15:23:39,312 [root] DEBUG: GetInjectionInfo: Failed to find InjectionInfoList.
2018-01-29 15:23:39,312 [root] DEBUG: NtMapViewOfSection hook: Added section view with handle 0xd4 and local view 0x2d40000 to global list.
2018-01-29 15:23:39,312 [root] INFO: Announced 32-bit process name: ELSCroxy.exe pid: 2036
2018-01-29 15:23:39,328 [lib.api.process] INFO: DLL to inject is dll\eAZjhii.dll
2018-01-29 15:23:39,328 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 15:23:39,358 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 2036
2018-01-29 15:23:39,375 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x250e40 for process 2036.
2018-01-29 15:23:39,390 [root] DEBUG: CreateProcessInternal hook: Injection info set for new process 2036, ImageBase: 0x400000
2018-01-29 15:23:39,405 [root] INFO: Process with pid 2396 has terminated
2018-01-29 15:23:39,437 [root] INFO: Disabling sleep skipping.
2018-01-29 15:23:39,437 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 15:23:39,483 [root] INFO: Added new process to list with pid: 2036
2018-01-29 15:23:39,483 [root] INFO: Cuckoomon successfully loaded in process with pid 2036.
2018-01-29 15:23:50,280 [root] DEBUG: GetInjectionInfo: Failed to find InjectionInfoList.
2018-01-29 15:23:50,296 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x2d1080 for process 2036.
2018-01-29 15:23:50,296 [root] DEBUG: NtOpenProcess: Injection info created for pid 2036.
2018-01-29 15:23:50,296 [root] DEBUG: NtOpenProcess: Image base for process 2036 (handle 0x140): 0x00400000.
2018-01-29 15:24:25,390 [root] DEBUG: NtMapViewOfSection hook: Added section view with handle 0x164 and local view 0x35c0000 to global list.
2018-01-29 15:24:25,390 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x2d6f10 for process 1916.
2018-01-29 15:24:25,390 [root] DEBUG: NtOpenProcess: Injection info created for pid 1916.
2018-01-29 15:24:25,405 [root] DEBUG: Error 5 (0x5) - get_process_image_base: ReadProcessMemory failed to read from 0x7FFDF000: Access is denied.
2018-01-29 15:24:25,405 [root] DEBUG: NtOpenProcess: Error obtaining target process image base for process 1916 (handle 0x144).
2018-01-29 15:24:25,421 [root] DEBUG: NtResumeThread hook: CurrentInjectionInfo 0x2d1080 (pid 2036).
2018-01-29 15:24:25,437 [root] DEBUG: DumpSectionViewsForPid: no shared section views found for pid 2036.
2018-01-29 15:24:25,437 [root] DEBUG: Error 5 (0x5) - get_process_image_base: ReadProcessMemory failed to read from 0x7FFDF000: Access is denied.
2018-01-29 15:24:25,453 [root] DEBUG: NtOpenProcess: Image base for process 1916 (handle 0x1a4): 0x00D30000.
2018-01-29 15:24:25,453 [root] INFO: Announced 32-bit process name: explorer.exe pid: 1916
2018-01-29 15:24:25,453 [lib.api.process] INFO: DLL to inject is dll\eAZjhii.dll
2018-01-29 15:24:25,453 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 15:24:25,500 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 1916
2018-01-29 15:24:25,515 [root] INFO: Announced 32-bit process name: explorer.exe pid: 1916
2018-01-29 15:24:25,515 [lib.api.process] INFO: DLL to inject is dll\eAZjhii.dll
2018-01-29 15:24:25,515 [lib.api.process] DEBUG: Using CreateRemoteThread injection.
2018-01-29 15:24:25,546 [root] INFO: Disabling sleep skipping.
2018-01-29 15:24:25,546 [root] DEBUG: NtResumeThread hook: CurrentInjectionInfo 0x2d6f10 (pid 1916).
2018-01-29 15:24:25,546 [root] DEBUG: NtResumeThread hook: Dumping hollowed process 1916, image base 0xd30000.
2018-01-29 15:24:25,546 [root] DEBUG: DumpProcess: Instantiating PeParser with address: 0xd30000
2018-01-29 15:24:25,546 [root] DEBUG: DumpProcess: Invalid PE file or invalid PE header.
2018-01-29 15:24:25,546 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 15:24:25,562 [root] DEBUG: NtResumeThread hook: Failed to dump PE image from buffer.
2018-01-29 15:24:25,562 [root] INFO: Added new process to list with pid: 1916
2018-01-29 15:24:25,562 [root] INFO: Cuckoomon successfully loaded in process with pid 1916.
2018-01-29 15:24:25,562 [root] DEBUG: DumpSectionViewsForPid: no shared section views found for pid 1916.
2018-01-29 15:24:26,000 [root] DEBUG: NtMapViewOfSection hook: Added section view with handle 0x1ac and local view 0x2f20000 to global list.
2018-01-29 15:24:26,000 [root] DEBUG: NtMapViewOfSection hook: Section view with handle 0x1ac and target process 1916.
2018-01-29 15:24:26,046 [root] DEBUG: NtMapViewOfSection hook: Added section view with handle 0x1ac and to target process 1916.
2018-01-29 15:24:26,108 [root] DEBUG: NtWriteVirtualMemory hook: Shellcode at 0x35b8d88 (size 0x318) injected into process 1916.
2018-01-29 15:24:26,108 [root] DEBUG: DumpMemory: CAPE output file successfully created: C:\xdpsrwa\CAPE\2036_1094624030212018
2018-01-29 15:24:26,108 [root] INFO: Added new CAPE file to list with path: C:\xdpsrwa\CAPE\2036_1094624030212018
2018-01-29 15:24:26,108 [root] DEBUG: NtWriteVirtualMemory hook: Dumped injected code from buffer.
2018-01-29 15:24:26,125 [root] DEBUG: NtSetContextThread hook: Hollow process entry point reset via NtSetContextThread to 0x1130000 (process 1916).
2018-01-29 15:24:26,125 [root] DEBUG: NtUnmapViewOfSection hook: Attempt to unmap view at 0x02F20000, faking.
2018-01-29 15:24:26,140 [root] DEBUG: NtResumeThread hook: CurrentInjectionInfo 0x2d6f10 (pid 1916).
2018-01-29 15:24:26,140 [root] DEBUG: NtResumeThread hook: Dumping hollowed process 1916, image base 0xd30000.
2018-01-29 15:24:26,140 [root] DEBUG: DumpProcess: Instantiating PeParser with address: 0xd30000
2018-01-29 15:24:26,155 [root] DEBUG: DumpProcess: Invalid PE file or invalid PE header.
2018-01-29 15:24:26,171 [root] DEBUG: NtResumeThread hook: Failed to dump PE image from buffer.
2018-01-29 15:24:26,171 [root] DEBUG: DumpSectionViewsForPid: Shared section view found with pid 1916.
2018-01-29 15:24:26,187 [root] DEBUG: ScanForPE: PE image located at: 0x2f20000
2018-01-29 15:24:26,203 [root] DEBUG: DumpSectionViewsForPid: Dumping PE image from shared section view, local address 0x2f20000.
2018-01-29 15:24:26,203 [root] DEBUG: DumpImageInCurrentProcess: Attempting to dump virtual PE image.
2018-01-29 15:24:26,217 [root] DEBUG: DumpProcess: Instantiating PeParser with address: 0x2f20000
2018-01-29 15:24:26,217 [root] DEBUG: DumpProcess: Module entry point VA is 0x2f21406
2018-01-29 15:24:26,265 [root] INFO: Added new CAPE file to list with path: C:\xdpsrwa\CAPE\2036_2184624030212018
2018-01-29 15:24:26,265 [root] DEBUG: DumpProcess: Module image dump success
2018-01-29 15:24:26,265 [root] DEBUG: DumpSectionViewsForPid: Dumped PE image from shared section view.
2018-01-29 15:24:26,265 [root] DEBUG: ScanForPE: PE image located at: 0x2f51c50
2018-01-29 15:24:26,280 [root] DEBUG: DumpSectionViewsForPid: Dumping PE image from shared section view, local address 0x2f51c50.
2018-01-29 15:24:26,280 [root] DEBUG: DumpImageInCurrentProcess: Attempting to dump 'raw' PE image.
2018-01-29 15:24:26,296 [root] DEBUG: DumpPE: Instantiating PeParser with address: 0x2f51c50
2018-01-29 15:24:26,312 [root] INFO: Added new CAPE file to list with path: C:\xdpsrwa\CAPE\2036_2964624030212018
2018-01-29 15:24:26,342 [root] DEBUG: DumpPE: PE file in memory dumped successfully.
2018-01-29 15:24:26,342 [root] DEBUG: DumpSectionViewsForPid: Dumped PE image from shared section view.
2018-01-29 15:24:26,358 [root] DEBUG: ScanForPE: No PE image located at 0x2f51c51.
2018-01-29 15:24:26,375 [root] DEBUG: GetInjectionInfo: Failed to find InjectionInfoList.
2018-01-29 15:24:26,375 [root] INFO: Notified of termination of process with pid 2036.
2018-01-29 15:24:26,375 [root] DEBUG: CreateInjectionInfo: Created injection info at 0x6534528 for process 1916.
2018-01-29 15:24:26,375 [root] DEBUG: NtOpenProcess: Injection info created for pid 1916.
2018-01-29 15:24:26,375 [root] INFO: Notified of termination of process with pid 3940.
2018-01-29 15:24:26,375 [root] DEBUG: NtOpenProcess: Image base for process 1916 (handle 0x384): 0x00D30000.
2018-01-29 15:24:26,515 [root] INFO: Notified of termination of process with pid 552.
2018-01-29 15:24:26,796 [root] INFO: Process with pid 552 has terminated
2018-01-29 15:24:26,796 [root] INFO: Process with pid 2036 has terminated
2018-01-29 15:24:27,796 [root] INFO: Process with pid 3940 has terminated
2018-01-29 15:28:23,812 [root] INFO: Analysis timeout hit, terminating analysis.
2018-01-29 15:28:23,812 [root] INFO: Created shutdown mutex.
2018-01-29 15:28:24,812 [root] INFO: Shutting down package.
2018-01-29 15:28:24,812 [root] INFO: Stopping auxiliary modules.
2018-01-29 15:28:30,312 [root] INFO: Terminating remaining processes before shutdown.
2018-01-29 15:28:30,312 [lib.api.process] INFO: Successfully terminated process with pid 1916.
2018-01-29 15:28:30,312 [root] INFO: Finishing auxiliary modules.
2018-01-29 15:28:30,328 [root] INFO: Shutting down pipe server and dumping dropped files.
2018-01-29 15:28:30,328 [root] INFO: Analysis completed.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

from cape.

enzok avatar enzok commented on July 19, 2024

It never gets submitted as a ursnif package in 32-bit mode. 64-bit mode does, but crashes as shown above.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Could you show me the log from the Ursnif package? Here are some lines that are worth checking:

2018-01-26 16:34:23,015 [root] INFO: Analysis package "Ursnif" has been specified.
...
2018-01-26 16:34:30,332 [root] INFO: Announced 64-bit process name: svchost.exe pid: 1540
...
2018-01-26 16:34:30,346 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-26 16:34:30,346 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
...
2018-01-26 16:34:30,487 [root] DEBUG: (1540) CAPE initialised: 64-bit Ursnif package. Loaded at 0x0000000073B50000
...
2018-01-26 16:34:30,736 [root] DEBUG: (1540) DumpCallback: Breakpoint 1 Size=0x0 and Address=0x00000000034215DE.
...
2018-01-26 16:34:30,878 [root] DEBUG: (1540) ConfigCallback: Config location set to Rcx: 0x0000000003CAEE50.

This is from job 4112 where svchost.exe is 64-bit (and so is the subsequent explorer.exe), 'DumpCallBack' dumps the payload after (hopefully) the .bss has been decrypted, and 'ConfigCallback' dumps the config region - it's worth checking the log for these, let me know what you find.

from cape.

enzok avatar enzok commented on July 19, 2024

This is from 64-bit VM, the log ends right after the bp is logged. The VM appears to crash.

32-bit is never recognized as a ursnif package.

2018-01-29 15:59:12,592 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 15:59:12,608 [root] INFO: Cuckoomon successfully loaded in process with pid 1344.
2018-01-29 15:59:14,467 [root] DEBUG: NtAllocateVirtualMemory hook, BaseAddress:0x1d90000, RegionSize: 0x5c000.
2018-01-29 15:59:14,467 [root] DEBUG: SetInitialWriteBreakpoint: AllocationBase: 0x1d90000, AllocationSize: 0x5c000, ThreadId: 0x8c8
2018-01-29 15:59:14,467 [root] DEBUG: SetDebugRegister: Setting breakpoint 0 hThread=0xac, Size=0x2, Address=0x1d90000 and Type=0x1.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I'm just not sure if it's the right package.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Also, maybe the 32-bit DLL is causing problems. You could comment it out like so in analyzer\windows\modules\packages\Ursnif.py:

    #self.options["dll"] = "Ursnif.dll"

Let me know if that helps.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I will hopefully be working on the updated 32-bit version today so if this is the problem I'll make sure it's fixed.

from cape.

enzok avatar enzok commented on July 19, 2024

Log from the 64-bit Ursnif package. This fails with cuckoo scheduler error - Analysis failed: system restarted unexpectedly

2018-01-29 16:18:32,000 [root] INFO: Date set to: 01-29-18, time set to: 21:18:32
2018-01-29 16:18:32,046 [root] DEBUG: Starting analyzer from: C:\eykaztnkou
2018-01-29 16:18:32,046 [root] DEBUG: Storing results at: C:\ObeNIRRqXC
2018-01-29 16:18:32,046 [root] DEBUG: Pipe server name: \\.\PIPE\DTRbQsrPdF
2018-01-29 16:18:32,046 [root] INFO: Analysis package "Ursnif" has been specified.
2018-01-29 16:18:32,687 [root] DEBUG: Started auxiliary module Auxfile
2018-01-29 16:18:32,687 [root] DEBUG: Started auxiliary module Browser
2018-01-29 16:18:32,703 [modules.auxiliary.digisig] DEBUG: Checking for a digitial signature.
2018-01-29 16:18:33,328 [modules.auxiliary.digisig] DEBUG: File is not signed.
2018-01-29 16:18:33,328 [modules.auxiliary.digisig] INFO: Uploading signature results to aux/DigiSig.json
2018-01-29 16:18:33,328 [root] DEBUG: Started auxiliary module DigiSig
2018-01-29 16:18:33,328 [root] DEBUG: Started auxiliary module Disguise
2018-01-29 16:18:33,328 [root] DEBUG: Started auxiliary module Human
2018-01-29 16:18:33,342 [root] DEBUG: Started auxiliary module Screenshots
2018-01-29 16:18:33,342 [root] DEBUG: Started auxiliary module Usage
2018-01-29 16:18:33,342 [root] INFO: Analyzer: DLL set to Ursnif.dll from package modules.packages.Ursnif
2018-01-29 16:18:33,342 [root] INFO: Analyzer: DLL_64 set to Ursnif_x64.dll from package modules.packages.Ursnif
2018-01-29 16:18:33,390 [lib.api.process] INFO: Successfully executed process from path "C:\Users\barry\AppData\Local\Temp\10348995c8c513d9b92b15272d37055f9488d449f60d0dca976e041e411f55e2.exe" with arguments "" with pid 1016
2018-01-29 16:18:33,390 [lib.api.process] INFO: DLL to inject is dll\uNYDYl.dll
2018-01-29 16:18:33,390 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 16:18:33,390 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-01-29 16:18:33,390 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-29 16:18:33,390 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-01-29 16:18:33,467 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 1016
2018-01-29 16:18:35,467 [lib.api.process] INFO: Successfully resumed process with pid 1016
2018-01-29 16:18:35,467 [root] INFO: Added new process to list with pid: 1016
2018-01-29 16:18:35,562 [root] DEBUG: CAPE debug - unrecognised key bp0.
2018-01-29 16:18:35,562 [root] DEBUG: CAPE debug - unrecognised key bp1.
2018-01-29 16:18:35,625 [root] DEBUG: WoW64 detected: 64-bit ntdll base: 0x77150000, KiUserExceptionDispatcher: 0x0, NtSetContextThread: 0x771a121a, Wow64PrepareForException: 0x0
2018-01-29 16:18:35,625 [root] DEBUG: WoW64 workaround: KiUserExceptionDispatcher hook installed at: 0x2b0000
2018-01-29 16:18:35,625 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 16:18:35,625 [root] INFO: Cuckoomon successfully loaded in process with pid 1016.
2018-01-29 16:18:40,530 [root] DEBUG: GetReturnAddress: Esp 0x0018FBB0, Ebp 0x0018FEB8.
2018-01-29 16:18:40,530 [root] DEBUG: NtOpenProcess hook: return address 0x00401879, allocation base 0x00400000.
2018-01-29 16:18:42,265 [root] DEBUG: GetReturnAddress: Esp 0x0018FB78, Ebp 0x0018FE80.
2018-01-29 16:18:42,265 [root] DEBUG: NtOpenProcess hook: return address 0x0040312B, allocation base 0x00400000.
2018-01-29 16:18:42,280 [root] INFO: Disabling sleep skipping.
2018-01-29 16:18:42,546 [root] INFO: Announced 32-bit process name: cmd.exe pid: 1840
2018-01-29 16:18:42,546 [lib.api.process] INFO: DLL to inject is dll\uNYDYl.dll
2018-01-29 16:18:42,546 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 16:18:42,546 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-01-29 16:18:42,546 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-29 16:18:42,546 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-01-29 16:18:42,562 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 1840
2018-01-29 16:18:42,578 [root] INFO: Notified of termination of process with pid 1016.
2018-01-29 16:18:42,625 [root] INFO: Process with pid 1016 has terminated
2018-01-29 16:18:42,765 [root] DEBUG: CAPE debug - unrecognised key bp0.
2018-01-29 16:18:42,765 [root] DEBUG: CAPE debug - unrecognised key bp1.
2018-01-29 16:18:42,858 [root] INFO: Disabling sleep skipping.
2018-01-29 16:18:42,905 [root] DEBUG: WoW64 detected: 64-bit ntdll base: 0x77150000, KiUserExceptionDispatcher: 0x0, NtSetContextThread: 0x771a121a, Wow64PrepareForException: 0x0
2018-01-29 16:18:42,905 [root] DEBUG: WoW64 workaround: KiUserExceptionDispatcher hook installed at: 0x160000
2018-01-29 16:18:42,953 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 16:18:42,953 [root] INFO: Added new process to list with pid: 1840
2018-01-29 16:18:42,953 [root] INFO: Cuckoomon successfully loaded in process with pid 1840.
2018-01-29 16:18:43,078 [root] INFO: Announced 32-bit process name: cmd.exe pid: 2496
2018-01-29 16:18:43,078 [lib.api.process] INFO: DLL to inject is dll\uNYDYl.dll
2018-01-29 16:18:43,078 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 16:18:43,125 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-01-29 16:18:43,125 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-29 16:18:43,125 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-01-29 16:18:43,171 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 2496
2018-01-29 16:18:43,280 [root] DEBUG: CAPE debug - unrecognised key bp0.
2018-01-29 16:18:43,280 [root] DEBUG: CAPE debug - unrecognised key bp1.
2018-01-29 16:18:43,296 [root] INFO: Disabling sleep skipping.
2018-01-29 16:18:43,328 [root] DEBUG: WoW64 detected: 64-bit ntdll base: 0x77150000, KiUserExceptionDispatcher: 0x0, NtSetContextThread: 0x771a121a, Wow64PrepareForException: 0x0
2018-01-29 16:18:43,328 [root] DEBUG: WoW64 workaround: KiUserExceptionDispatcher hook installed at: 0x1a0000
2018-01-29 16:18:43,328 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 16:18:43,358 [root] INFO: Added new process to list with pid: 2496
2018-01-29 16:18:43,358 [root] INFO: Cuckoomon successfully loaded in process with pid 2496.
2018-01-29 16:18:43,390 [root] INFO: Announced 32-bit process name: Authsitf.exe pid: 548
2018-01-29 16:18:43,390 [lib.api.process] INFO: DLL to inject is dll\uNYDYl.dll
2018-01-29 16:18:43,390 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 16:18:43,405 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-01-29 16:18:43,405 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-29 16:18:43,405 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-01-29 16:18:43,405 [lib.api.process] INFO: Injected into suspended 32-bit process with pid 548
2018-01-29 16:18:43,453 [root] DEBUG: CAPE debug - unrecognised key bp0.
2018-01-29 16:18:43,453 [root] DEBUG: CAPE debug - unrecognised key bp1.
2018-01-29 16:18:43,500 [root] INFO: Disabling sleep skipping.
2018-01-29 16:18:43,500 [root] DEBUG: WoW64 detected: 64-bit ntdll base: 0x77150000, KiUserExceptionDispatcher: 0x0, NtSetContextThread: 0x771a121a, Wow64PrepareForException: 0x0
2018-01-29 16:18:43,546 [root] DEBUG: WoW64 workaround: KiUserExceptionDispatcher hook installed at: 0x2f0000
2018-01-29 16:18:43,592 [root] DEBUG: CAPE initialised (32-bit).
2018-01-29 16:18:43,592 [root] INFO: Added new process to list with pid: 548
2018-01-29 16:18:43,592 [root] INFO: Cuckoomon successfully loaded in process with pid 548.
2018-01-29 16:18:45,905 [root] DEBUG: GetReturnAddress: Esp 0x0018FBB0, Ebp 0x0018FEB8.
2018-01-29 16:18:45,905 [root] DEBUG: NtOpenProcess hook: return address 0x00401879, allocation base 0x00400000.
2018-01-29 16:18:47,280 [root] DEBUG: GetReturnAddress: Esp 0x0018FB78, Ebp 0x0018FE80.
2018-01-29 16:18:47,296 [root] DEBUG: NtOpenProcess hook: return address 0x0040312B, allocation base 0x00400000.
2018-01-29 16:18:47,328 [root] DEBUG: GetReturnAddress: Esp 0x0018FB38, Ebp 0x0018FE40.
2018-01-29 16:18:47,328 [root] DEBUG: NtOpenProcess hook: return address 0x00401A14, allocation base 0x00400000.
2018-01-29 16:18:47,328 [root] DEBUG: GetReturnAddress: Esp 0x0018FB50, Ebp 0x0018FE58.
2018-01-29 16:18:47,342 [root] DEBUG: NtOpenProcess hook: return address 0x004046B9, allocation base 0x00400000.
2018-01-29 16:18:47,342 [root] INFO: Announced 64-bit process name: svchost.exe pid: 2392
2018-01-29 16:18:47,342 [lib.api.process] INFO: DLL to inject is dll\zCeCbj.dll
2018-01-29 16:18:47,342 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 16:18:47,358 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-01-29 16:18:47,358 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-29 16:18:47,358 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-01-29 16:18:47,421 [lib.api.process] INFO: Injected into suspended 64-bit process with pid 2392
2018-01-29 16:18:47,608 [root] INFO: Announced 64-bit process name: svchost.exe pid: 2392
2018-01-29 16:18:47,608 [lib.api.process] INFO: DLL to inject is dll\zCeCbj.dll
2018-01-29 16:18:47,608 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 16:18:47,608 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-01-29 16:18:47,608 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-29 16:18:47,608 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-01-29 16:18:47,703 [root] DEBUG: (0) bp0 set to 0x4ee4
2018-01-29 16:18:47,750 [root] DEBUG: (0) bp1 set to 0x233f1
2018-01-29 16:18:47,765 [root] INFO: Announced 64-bit process name: svchost.exe pid: 2392
2018-01-29 16:18:47,765 [root] INFO: Disabling sleep skipping.
2018-01-29 16:18:47,765 [lib.api.process] INFO: DLL to inject is dll\zCeCbj.dll
2018-01-29 16:18:47,765 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-01-29 16:18:47,765 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-01-29 16:18:47,780 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-01-29 16:18:47,780 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-01-29 16:18:47,812 [root] DEBUG: (2392) CAPE initialised: 64-bit Ursnif package. Loaded at 0x00000000734C0000
2018-01-29 16:18:47,858 [root] INFO: Added new process to list with pid: 2392
2018-01-29 16:18:47,858 [root] INFO: Cuckoomon successfully loaded in process with pid 2392.
2018-01-29 16:18:48,155 [root] INFO: Notified of termination of process with pid 548.
2018-01-29 16:18:48,155 [root] INFO: Notified of termination of process with pid 2496.
2018-01-29 16:18:48,171 [root] INFO: Notified of termination of process with pid 1840.
2018-01-29 16:18:48,203 [root] DEBUG: (2392) lstrcpynA hook: Ursnif payload marker.
2018-01-29 16:18:48,203 [root] DEBUG: (2392) GetReturnAddress: Rsp 0x00000000000AF3A0, Rip 0x00000000734C129A.
2018-01-29 16:18:48,217 [root] DEBUG: (2392) GetHookCallerBase: thread 2488 (handle 0xbc), return address 0x000000000303150B, allocation base 0x0000000003030000.
2018-01-29 16:18:48,217 [root] DEBUG: (2392) FileOffsetToVA: Virtual Address = 0x0000000003035AE4.
2018-01-29 16:18:48,233 [root] DEBUG: (2392) SetDebugRegister: Setting breakpoint 0 hThread=0xbc, Size=0x0, Address=0x0000000003035AE4 and Type=0x0.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Ok that makes it clear - thanks for the extra detail. Definitely the 64-bit DLL then, as you say the setting of the first breakpoint seems to be triggering it. But I am still perplexed as to why it would cause a full system reboot! I've tested this package on a few systems,, I'll see if I can come up with a new build to try and find out a bit more... Shall I email you the new build?

from cape.

enzok avatar enzok commented on July 19, 2024

Sure I'm happy to test it. Thanks.

from cape.

enzok avatar enzok commented on July 19, 2024

32-bit samples aren't hitting on the decrypt, crypto, or parse_config yara rules. 64-bit samples appear to be fine. That could explain the not getting submitted to ursnif package.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Yeah I've only catered for 64-bit so far. I still need to extend the signature and update the DLL for 32-bit.

from cape.

enzok avatar enzok commented on July 19, 2024

I used the new DLL, same error: system restarted unexpectedly.

18-01-30 14:35:59,592 [root] DEBUG: (2992) CAPE initialised: 64-bit Ursnif package. Loaded at 0x00000000751C0000
2018-01-30 14:35:59,608 [root] INFO: Added new process to list with pid: 2992
2018-01-30 14:35:59,608 [root] INFO: Cuckoomon successfully loaded in process with pid 2992.
2018-01-30 14:35:59,796 [root] INFO: Notified of termination of process with pid 1164.
2018-01-30 14:35:59,796 [root] DEBUG: (2992) lstrcpynA hook: Ursnif payload marker.
2018-01-30 14:35:59,812 [root] INFO: Notified of termination of process with pid 2604.
2018-01-30 14:35:59,812 [root] DEBUG: (2992) GetReturnAddress: Rsp 0x000000000012F420, Rip 0x00000000751C129A.
2018-01-30 14:35:59,812 [root] DEBUG: (2992) GetHookCallerBase: thread 2996 (handle 0xc0), return address 0x000000000314150B, allocation base 0x0000000003140000.
2018-01-30 14:35:59,812 [root] DEBUG: (2992) FileOffsetToVA: Virtual Address = 0x0000000003145AE4.
2018-01-30 14:35:59,842 [root] DEBUG: (2992) SetDebugRegister: Setting breakpoint 0 hThread=0xc0, Size=0x0, Address=0x0000000003145AE4 and Type=0x0.
2018-01-30 14:35:59,842 [root] DEBUG: (2992) SetDebugRegister: SetThreadContext succeeded.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hmm well we got a bit more information - the next line should be:

SetThreadBreakpoint: Set bp 0 thread id 1992 type 0 at address 0x0000000003425AE4, size 0 with Callback 0x73b63970

So if you are happy to test another iteration (and maybe more) we can zero in on where the problem must lie if I keep adding debug output lines until we find the exact place...

from cape.

enzok avatar enzok commented on July 19, 2024

here's results from the 2nd dll you sent me
same error message

2018-01-30 19:09:43,140 [root] DEBUG: (920) CAPE initialised: 64-bit Ursnif package. Loaded at 0x0000000073570000
2018-01-30 19:09:43,171 [root] INFO: Added new process to list with pid: 920
2018-01-30 19:09:43,171 [root] INFO: Cuckoomon successfully loaded in process with pid 920.
2018-01-30 19:09:43,483 [root] DEBUG: (920) lstrcpynA hook: Ursnif payload marker.
2018-01-30 19:09:43,483 [root] INFO: Notified of termination of process with pid 1704.
2018-01-30 19:09:43,483 [root] DEBUG: (920) GetReturnAddress: Rsp 0x000000000028F600, Rip 0x000000007357129A.
2018-01-30 19:09:43,483 [root] INFO: Notified of termination of process with pid 3036.
2018-01-30 19:09:43,483 [root] DEBUG: (920) GetHookCallerBase: thread 2068 (handle 0xbc), return address 0x000000000320150B, allocation base 0x0000000003200000.
2018-01-30 19:09:43,500 [root] DEBUG: (920) FileOffsetToVA: Virtual Address = 0x0000000003205AE4.
2018-01-30 19:09:43,515 [root] DEBUG: (920) SetBreakpoint: About to call SetThreadBreakpoint for thread 2068.
2018-01-30 19:09:43,515 [root] INFO: Notified of termination of process with pid 2864.
2018-01-30 19:09:43,515 [root] DEBUG: (920) SetDebugRegister: Setting breakpoint 0 hThread=0xbc, Size=0x0, Address=0x0000000003205AE4 and Type=0x0.
2018-01-30 19:09:43,530 [root] DEBUG: (920) SetDebugRegister: SetThreadContext succeeded.```

from cape.

enzok avatar enzok commented on July 19, 2024

I tried running it against a new VM build, but same result.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Thanks for testing that - it's beginning to look like the crash is occurring in or around the 'SetThreadBreakpoint' function. I've just created (and sent) another build with even more debug statements around the suspected code, if you wouldn't mind giving it a run that would be really helpful. Also, out of interest, what hypervisor do you use in your setup?

from cape.

enzok avatar enzok commented on July 19, 2024

KVM

from cape.

enzok avatar enzok commented on July 19, 2024

Same result. Not sure if it helps but the Extraction package also terminates unexpectedly. Could it be hypervisor related?

2018-02-01 11:20:15,703 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-02-01 11:20:15,703 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-02-01 11:20:15,750 [root] DEBUG: (1712) CAPE initialised: 64-bit Ursnif package. Loaded at 0x00000000734C0000
2018-02-01 11:20:15,921 [root] INFO: Added new process to list with pid: 1712
2018-02-01 11:20:15,921 [root] INFO: Cuckoomon successfully loaded in process with pid 1712.
2018-02-01 11:20:16,171 [root] DEBUG: (1712) lstrcpynA hook: Ursnif payload marker.
2018-02-01 11:20:16,171 [root] INFO: Notified of termination of process with pid 1704.
2018-02-01 11:20:16,171 [root] DEBUG: (1712) GetReturnAddress: Rsp 0x00000000000EF500, Rip 0x00000000734C129A.
2018-02-01 11:20:16,187 [root] INFO: Notified of termination of process with pid 3036.
2018-02-01 11:20:16,187 [root] DEBUG: (1712) GetHookCallerBase: thread 1104 (handle 0xbc), return address 0x0000000001C1150B, allocation base 0x0000000001C10000.
2018-02-01 11:20:16,187 [root] DEBUG: (1712) FileOffsetToVA: Virtual Address = 0x0000000001C15AE4.
2018-02-01 11:20:16,187 [root] DEBUG: (1712) SetDebugRegister: Setting breakpoint 0 hThread=0xbc, Size=0x0, Address=0x0000000001C15AE4 and Type=0x0.
2018-02-01 11:20:16,203 [root] DEBUG: (1712) SetDebugRegister: SetThreadContext succeeded.
2018-02-01 11:20:16,203 [root] INFO: Notified of termination of process with pid 1120.```

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

It's a tricky one - I guess we can't yet rule out it being the hypervisor. I've not seen this issue on either VMware ESX or Workstation... Another potential might be the OS or patch level - is it running on Windows 7 x64? Let me know if you patch the VMs (all mine are SP1 but no more).

In your previous log there is one of the extra lines I added:

SetBreakpoint: About to call SetThreadBreakpoint for thread 2068.

This is missing from the most recent one which is another mystery. I've just compiled yet another with a line at the beginning of the SetThreadBreakpoint function so we should see that appear before the SetDebugRegister call. Let me know if you get any more output from this one.

from cape.

enzok avatar enzok commented on July 19, 2024

Two VMs both win7x64 w/SP1 - one has no additional patches, the other has most recent, same behavior from both.

2018-02-01 14:43:31,062 [lib.api.process] INFO: DLL to inject is dll\otzhHB.dll
2018-02-01 14:43:31,062 [root] DEBUG: (2516) CAPE initialised: 64-bit Ursnif package. Loaded at 0x00000000734C0000
2018-02-01 14:43:31,062 [lib.api.process] DEBUG: Using QueueUserAPC injection.
2018-02-01 14:43:31,062 [lib.api.process] INFO: Option 'exclude-apis' with value 'NtCreateFile:NtWriteFile:NtDeleteFile:NtQueryInformationFile' sent to monitor
2018-02-01 14:43:31,062 [lib.api.process] INFO: Option 'bp0' with value '20196' sent to monitor
2018-02-01 14:43:31,062 [lib.api.process] INFO: Option 'bp1' with value '144369' sent to monitor
2018-02-01 14:43:31,203 [root] INFO: Added new process to list with pid: 2516
2018-02-01 14:43:31,203 [root] INFO: Cuckoomon successfully loaded in process with pid 2516.
2018-02-01 14:43:31,390 [root] DEBUG: (2516) lstrcpynA hook: Ursnif payload marker.
2018-02-01 14:43:31,390 [root] INFO: Notified of termination of process with pid 1904.
2018-02-01 14:43:31,390 [root] DEBUG: (2516) GetReturnAddress: Rsp 0x00000000000EF0C0, Rip 0x00000000734C129A.
2018-02-01 14:43:31,390 [root] INFO: Notified of termination of process with pid 2120.
2018-02-01 14:43:31,390 [root] DEBUG: (2516) GetHookCallerBase: thread 2308 (handle 0xb8), return address 0x00000000030A150B, allocation base 0x00000000030A0000.
2018-02-01 14:43:31,405 [root] DEBUG: (2516) FileOffsetToVA: Virtual Address = 0x00000000030A5AE4.
2018-02-01 14:43:31,405 [root] DEBUG: (2516) SetBreakpoint: About to call SetThreadBreakpoint for thread 2308.
2018-02-01 14:43:31,405 [root] DEBUG: (2516) SetThreadBreakpoint: Function entry for thread 2308.
2018-02-01 14:43:31,421 [root] INFO: Notified of termination of process with pid 2544.
2018-02-01 14:43:31,421 [root] DEBUG: (2516) SetThreadBreakpoint: About to create SetBreakpointThread thread.
2018-02-01 14:43:31,421 [root] DEBUG: (2516) SetDebugRegister: Setting breakpoint 0 hThread=0xb8, Size=0x0, Address=0x00000000030A5AE4 and Type=0x0.
2018-02-01 14:43:31,421 [root] DEBUG: (2516) SetDebugRegister: SetThreadContext succeeded.```

from cape.

enzok avatar enzok commented on July 19, 2024

i'm going to try moving the VM into vmware and see if it still behaves the same

from cape.

enzok avatar enzok commented on July 19, 2024

haven't had much luck with vmware

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Hi enzo, I've just pushed an update to the Ursnif package which should now cover both 32-bit and 64-bit systems, as well as working on some recent samples. I have added to the Yara sig, but it's starting to look pretty bloated and unwieldy so I'd like to remove most of it leaving only the 'crypto' and 'parse_config' bits for each platform. Can you let me know if you have any samples that these bits won't detect as I don't want to break older detection.

As far as your crashes/restarts are concerned, it might be worth testing the new package on your system (particularly if you have a 32-bit vm), although I guess it's likely to have the same problem as before. Did you manage to test on VMware? I'm very curious to know if this is a problem with KVM specifically. One other thing it might be worth trying is to test another package which relies on the debugger to see if it's this that causes the restarts. A Sedreco sample such as e1259372d15bb5001be18f03dddbdc117710d7a64829dad3a95829413783f0d7 should test an older version of the debugger on 64-bit. Let me know how you go.

from cape.

enzok avatar enzok commented on July 19, 2024

I get the same error with the Sedreco sample, and the new Ursnif32/64 DLLs. Looks like it may be KVM specific. I have to build a new VM from scratch to test VMware as converting to vmdk didn't get me far.

As to the yara rules, the simpler the better. I would have to rerun my samples against the Cape injection files to see if they still work after being pared down.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I found some bits on the web suggesting that KVM doesn't allow for use of the debug registers in the guest and takes a vmexit if they're touched. There's also a couple of patches to allow for their use or prevent the restarts but they're from a few years ago so there may be more up-to-date info.

https://patchwork.kernel.org/patch/4717311/
https://bugzilla.redhat.com/show_bug.cgi?id=1068627
https://patchwork.kernel.org/patch/8436261/

from cape.

enzok avatar enzok commented on July 19, 2024

I Googled for this, but haven't found anything that spells out a solution.

from cape.

enzok avatar enzok commented on July 19, 2024

I'm considering migrating my VMs to ESX, but the cuckoo conf says it isn't possible to create memory dumps with ESX. Can you verify this?

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I think this must be 'whole system' memory dumps taken by the hypervisor. I haven't ever used this functionality myself but would be surprised if it can't be done with VMware as I've heard of .vmem files from snapshots being used - in forensics for example. I'm not sure how though. But the process memory dumps taken within the guest work fine in case this is what you meant?

from cape.

enzok avatar enzok commented on July 19, 2024

I was referring to system dumps for Volatility analysis. I've taken a poll and most of are willing to lose that capability to have fully working CAPE. As soon as I get some time I'll be migrating our VMs to ESX. You're right about the .vmem file, just have to take a snapshot of the running VM and copy it over. Shouldn't be too difficult to accomplish. Maybe I'll take a stab at that down the road. Thanks.

from cape.

peter9823 avatar peter9823 commented on July 19, 2024

Trying to get the config from this sample fails:
https://cape.contextis.com/analysis/5415/
2018-03-12 09:59:53,690 [root] DEBUG: (1632) SetInitialBreakpoint: Error - No address specified for Ursnif breakpoints.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

Thanks for the notice - I will publish an update on this soon.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I have just published an update to the Ursnif package to handle this and other recent variants. Here is the sample you mention:

https://cape.contextis.com/analysis/6177

Please note that in order to achieve extraction of config and payload, breakpoint addresses need to be supplied to the Ursnif package. This is done automatically in CAPE when the payload is extracted by the Injection package, so in order for complete automation be sure to submit with either the Injection package or no package (auto).

To submit directly with the Ursnif package, you may use the Ursnif Yara signature to find the addresses of the two required breakpoints - for example:

D:>yara -s D:\CAPE\cape\data\yara\CAPE\Ursnif.yar D:\payloads\1f4ab93b10fdf93ff51200991c2a32f90861c8dd3396159d1735198306ac0cb6
Ursnif D:\payloads\1f4ab93b10fdf93ff51200991c2a32f90861c8dd3396159d1735198306ac0cb6
0x2a1e2:$crypto64_3: 33 C6 FF C7 49 83 C2 04 33 C3 8B F1 8B CF D3 C8 89 02 48 83 C2 04 41 83 C3 FF 75 D0 45 85 C9 75 1A 41 83 E0 03
0x1f09c:$decrypt_config64: 44 8B D9 33 C0 45 33 C9 44 33 1D 65 A0 01 00 4C 8B D2 48 85 D2 74 37 4C 8D 42 10 45 3B 0A 73 2E 45 39 58 F8 75 1C 41 F6 40 FC 01 74 12

You would then convert these addresses to decimal and add the following line to the options:

bp0=127132,bp1=172514

Note that the config breakpoint must be bp0, and payload bp1, not the other way around!

Let me know if you have any problems.

from cape.

kevoreilly avatar kevoreilly commented on July 19, 2024

I'm glad to say this is now done and dusted - the latest samples at the time of writing are working (e.g. https://cape.contextis.com/analysis/6654) so I can finally close this issue!

from cape.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.