Leaderboard

Lamultzani! http://rstelion.cf/

La Multi Ani !

https://www.youtube.com/watch?v=OZxeZSJ4PlU La multi ani tovarasi colegi de forum!

Lma

///

[Note] Learning KVM - implement your own Linux kernel Few weeks ago I solved a great KVM escaping challenge from TWCTF hosted by @TokyoWesterns. I have given a writeup on my blog: [Write-up] TokyoWesterns CTF 2018 - pwn240+300+300 EscapeMe, but it mentions nothing about KVM because there's no bug (at least I didn't find) around it. Most introduction of KVM I found are actually introducing either libvirt or qemu, lack of how to utilize KVM by hand, that's why I have this post. This thread is a good start to implement a simple KVM program. Some projects such as kvm-hello-world and kvmtool are worthy to take a look as well. And OSDev.org has great resources to learn system architecture knowledge. In this post I will introduce how to use KVM directly and how it works, wish this article can be a quick start for beginners learning KVM. I've created a public repository for the source code of KVM-based hypervisor and the kernel: david942j/kvm-kernel-example. You can clone and try it after reading this article. Warning: all code in this post may be simplified to clearly show its function, if you want to write some code, I highly recommend you read examples in the repository instead of copy-paste code from here. The kernel I implemented is able to execute an ELF in user-space, this is the screenshot of execution result: Introduction KVM (Kernel-base Virtual Machine) is a virtual machine that implemented native in Linux kernel. As you know, VM usually used for creating a separated and independent environment. As the official site described, each virtual machine created by KVM has private virtualized hardware: a network card, disk, graphics adapter, etc. First I'll introduce how to use KVM to execute simple assembled code, and then describe some key points to implement a Linux kernel. The Linux kernel we will implement is extremely simple, but more features might be added after this post released. Get Started All communication with KVM is done by the ioctl syscall, which is usually used for getting and setting device status. Creating a KVM-based VM basically needs 7 steps: Open the KVM device, kvmfd=open("/dev/kvm", O_RDWR|O_CLOEXEC) Do create a VM, vmfd=ioctl(kvmfd, KVM_CREATE_VM, 0) Set up memory for VM guest, ioctl(vmfd, KVM_SET_USER_MEMORY_REGION, &region) Create a virtual CPU for the VM, vcpufd=ioctl(vmfd, KVM_CREATE_VCPU, 0) Set up memory for the vCPU vcpu_size=ioctl(kvmfd, KVM_GET_VCPU_MMAP_SIZE, NULL) run=(struct kvm_run*)mmap(NULL, mmap_size, PROT_READ|PROT_WRITE, MAP_SHARED, vcpufd, 0) Put assembled code on user memory region, set up vCPU's registers such as rip Run and handle exit reason. while(1) { ioctl(vcpufd, KVM_RUN, 0); ... } Too complicated!? See this figure A VM needs user memory region and virtual CPU(s), so all we need is to create VM, set up user memory region, create vCPU(s) and its working space then execute it! Code is better than plaintext for hackers. Warning: code posted here has no error handling. Step 1 - 3, set up a new VM /* step 1~3, create VM and set up user memory region */ void kvm(uint8_t code[], size_t code_len) { // step 1, open /dev/kvm int kvmfd = open("/dev/kvm", O_RDWR|O_CLOEXEC); if(kvmfd == -1) errx(1, "failed to open /dev/kvm"); // step 2, create VM int vmfd = ioctl(kvmfd, KVM_CREATE_VM, 0); // step 3, set up user memory region size_t mem_size = 0x40000000; // size of user memory you want to assign void *mem = mmap(0, mem_size, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0); int user_entry = 0x0; memcpy((void*)((size_t)mem + user_entry), code, code_len); struct kvm_userspace_memory_region region = { .slot = 0, .flags = 0, .guest_phys_addr = 0, .memory_size = mem_size, .userspace_addr = (size_t)mem }; ioctl(vmfd, KVM_SET_USER_MEMORY_REGION, &region); /* end of step 3 */ // not finished ... } In above code fragment I assign 1GB memory (mem_size) to the guest, and put assembled code on the first page. Later we will set the instruction pointer to 0x0 (user_entry), where the guest should start to execute. Step 4 - 6, set up a new vCPU /* step 4~6, create and set up vCPU */ void kvm(uint8_t code[], size_t code_len) { /* ... step 1~3 omitted */ // step 4, create vCPU int vcpufd = ioctl(vmfd, KVM_CREATE_VCPU, 0); // step 5, set up memory for vCPU size_t vcpu_mmap_size = ioctl(kvmfd, KVM_GET_VCPU_MMAP_SIZE, NULL); struct kvm_run* run = (struct kvm_run*) mmap(0, vcpu_mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED, vcpufd, 0); // step 6, set up vCPU's registers /* standard registers include general-purpose registers and flags */ struct kvm_regs regs; ioctl(vcpufd, KVM_GET_REGS, &regs); regs.rip = user_entry; regs.rsp = 0x200000; // stack address regs.rflags = 0x2; // in x86 the 0x2 bit should always be set ioctl(vcpufd, KVM_SET_REGS, &regs); // set registers /* special registers include segment registers */ struct kvm_sregs sregs; ioctl(vcpufd, KVM_GET_SREGS, &sregs); sregs.cs.base = sregs.cs.selector = 0; // let base of code segment equal to zero ioctl(vcpufd, KVM_SET_SREGS, &sregs); // not finished ... } Here we create a vCPU and set up its registers include standard registers and "special" registers. Each kvm_run structure corresponds to one vCPU, and we will use it to get the CPU status after execution. Notice that we can create multiple vCPUs under one VM, then with multithread we can emulate a VM with multiple CPUs. Note: by default, the vCPU runs in real mode, which only executes 16-bit assembled code. To run 32 or 64-bit, the page table must be set up, which we'll describe later. Step 7, execute! /* last step, run it! */ void kvm(uint8_t code[], size_t code_len) { /* ... step 1~6 omitted */ // step 7, execute vm and handle exit reason while (1) { ioctl(vcpufd, KVM_RUN, NULL); switch (run->exit_reason) { case KVM_EXIT_HLT: fputs("KVM_EXIT_HLT", stderr); return 0; case KVM_EXIT_IO: /* TODO: check port and direction here */ putchar(*(((char *)run) + run->io.data_offset)); break; case KVM_EXIT_FAIL_ENTRY: errx(1, "KVM_EXIT_FAIL_ENTRY: hardware_entry_failure_reason = 0x%llx", run->fail_entry.hardware_entry_failure_reason); case KVM_EXIT_INTERNAL_ERROR: errx(1, "KVM_EXIT_INTERNAL_ERROR: suberror = 0x%x", run->internal.suberror); case KVM_EXIT_SHUTDOWN: errx(1, "KVM_EXIT_SHUTDOWN"); default: errx(1, "Unhandled reason: %d", run->exit_reason); } } } Typically we only care about the first two cases, KVM_EXIT_HLT and KVM_EXIT_IO. With instruction hlt, the KVM_EXIT_HLT is triggered. Instructions in and out trigger KVM_EXIT_IO. And not only for I/O, we can also use this as hypercall, i.e. to communicate with the host. Here we only print one character sent to device. ioctl(vcpufd, KVM_RUN, NULL) will run until an exit-like instruction occurred (such as hlt, out, or an error). You can also enable the single-step mode (not demonstrated here), then it will stop on every instructions. Let's try our first KVM-based VM: int main() { /* .code16 mov al, 0x61 mov dx, 0x217 out dx, al mov al, 10 out dx, al hlt */ uint8_t code[] = "\xB0\x61\xBA\x17\x02\xEE\xB0\n\xEE\xF4"; kvm(code, sizeof(code)); } And the execution result is: $ ./kvm a KVM_EXIT_HLT 64-bit World To execute 64-bit assembled code, we need to set vCPU into long mode. And this wiki page describes how to switch from real mode to long mode, I highly recommend you read it as well. The most complicated part of switching into long mode is to set up the page tables for mapping virtual address into physical address. x86-64 processor uses a memory management feature named PAE (Physical Address Extension), contains of four kinds of tables: PML4T, PDPT, PDT, and PT. The way these tables work is that each entry in the PML4T points to a PDPT, each entry in a PDPT to a PDT and each entry in a PDT to a PT. Each entry in a PT then points to the physical address. source: https://commons.wikimedia.org The figure above is called 4K paging. There's another paging method named 2M paging, with the PT (page table) removed. In this method the PDT entries point to physical address. The control registers (cr*) are used for setting paging attributes. For example, cr3 should point to physical address of pml4. More information about control registers can be found in wikipedia. This code set up the tables, using the 2M paging. /* Maps: 0 ~ 0x200000 -> 0 ~ 0x200000 */ void setup_page_tables(void *mem, struct kvm_sregs *sregs){ uint64_t pml4_addr = 0x1000; uint64_t *pml4 = (void *)(mem + pml4_addr); uint64_t pdpt_addr = 0x2000; uint64_t *pdpt = (void *)(mem + pdpt_addr); uint64_t pd_addr = 0x3000; uint64_t *pd = (void *)(mem + pd_addr); pml4[0] = 3 | pdpt_addr; // PDE64_PRESENT | PDE64_RW | pdpt_addr pdpt[0] = 3 | pd_addr; // PDE64_PRESENT | PDE64_RW | pd_addr pd[0] = 3 | 0x80; // PDE64_PRESENT | PDE64_RW | PDE64_PS sregs->cr3 = pml4_addr; sregs->cr4 = 1 << 5; // CR4_PAE; sregs->cr4 |= 0x600; // CR4_OSFXSR | CR4_OSXMMEXCPT; /* enable SSE instruction */ sregs->cr0 = 0x80050033; // CR0_PE | CR0_MP | CR0_ET | CR0_NE | CR0_WP | CR0_AM | CR0_PG sregs->efer = 0x500; // EFER_LME | EFER_LMA } There're some control bits record in the tables, include if the page is mapped, is writable, and can be accessed in user-mode. e.g. 3 (PDE64_PRESENT|PDE64_RW) stands for the memory is mapped and writable, and 0x80 (PDE64_PS) stands for it's 2M paging instead of 4K. As a result, these page tables can map address below 0x200000 to itself (i.e. virtual address equals to physical address). Remaining is setting segment registers: void setup_segment_registers(struct kvm_sregs *sregs) { struct kvm_segment seg = { .base = 0, .limit = 0xffffffff, .selector = 1 << 3, .present = 1, .type = 11, /* execute, read, accessed */ .dpl = 0, /* privilege level 0 */ .db = 0, .s = 1, .l = 1, .g = 1, }; sregs->cs = seg; seg.type = 3; /* read/write, accessed */ seg.selector = 2 << 3; sregs->ds = sregs->es = sregs->fs = sregs->gs = sregs->ss = seg; } We only need to modify VM setup in step 6 to support 64-bit instructions, change code from sregs.cs.base = sregs.cs.selector = 0; // let base of code segment equal to zero to setup_page_tables(mem, &sregs); setup_segment_registers(&sregs); Now we can execute 64-bit assembled code. int main() { /* movabs rax, 0x0a33323144434241 push 8 pop rcx mov edx, 0x217 OUT: out dx, al shr rax, 8 loop OUT hlt */ uint8_t code[] = "H\xB8\x41\x42\x43\x44\x31\x32\x33\nj\bY\xBA\x17\x02\x00\x00\xEEH\xC1\xE8\b\xE2\xF9\xF4"; kvm(code, sizeof(code)); } And the execution result is: $ ./kvm64 ABCD123 KVM_EXIT_HLT The source code of hypervisor can be found in the repository/hypervisor. So far you are already able to run x86-64 assembled code under KVM, so our introduction to KVM is almost finished (except handling hypercalls). In the next section I will describe how to implement a simple kernel, which contains some OS knowledge. If you are interesting in how kernel works, go ahead. Kernel Before implementing a kernel, some questions need to be dealt with: How CPU distinguishes between kernel-mode and user-mode? How could CPU transfer control to kernel when user invokes syscall? How kernel switches between kernel and user? kernel-mode v.s. user-mode An important difference between kernel-mode and user-mode is some instructions can only be executed under kernel-mode, such as hlt and wrmsr. The two modes are distinguish by the dpl (descriptor privilege level) field in segment register cs. dpl=3 in cs for user-mode, and zero for kernel-mode (not sure if this "level" equivalent to so-called ring3 and ring0). In real mode kernel should handle the segment registers carefully, while in x86-64, instructions syscall and sysret will properly set segment registers automatically, so we don't need to maintain segment registers manually. And another difference is the permission setting in page tables. In the above example I set all entries as non-user-accessible: pml4[0] = 3 | pdpt_addr; // PDE64_PRESENT | PDE64_RW | pdpt_addr pdpt[0] = 3 | pd_addr; // PDE64_PRESENT | PDE64_RW | pd_addr pd[0] = 3 | 0x80; // PDE64_PRESENT | PDE64_RW | PDE64_PS If kernel wants to create virtual memory for user-space, such as handling mmap syscall from user, the page tables must set the 3rd bit, i.e. have bit (1 << 2) set, then the page can be accessed in user-space. For example, pml4[0] = 7 | pdpt_addr; // PDE64_USER | PDE64_PRESENT | PDE64_RW | pdpt_addr pdpt[0] = 7 | pd_addr; // PDE64_USER | PDE64_PRESENT | PDE64_RW | pd_addr pd[0] = 7 | 0x80; // PDE64_USER | PDE64_PRESENT | PDE64_RW | PDE64_PS This is just an example, we should NOT set user-accessible pages in hypervisor, user-accessible pages should be handled by our kernel. Syscall There's a special register can enable syscall/sysenter instruction: EFER (Extended Feature Enable Register). We have used it for entering long mode before: sregs->efer = 0x500; // EFER_LME | EFER_LMA LME and LMA stand for Long Mode Enable and Long Mode Active, respectively. To enable syscall as well, we should do sregs->efer |= 0x1; // EFER_SCE We also need to register syscall handler so that CPU knows where to jump when user invokes syscalls. And of course, this registration should be done in kernel instead of hypervisor. Registration of syscall handler can be achieved via setting special registers named MSR (Model Specific Registers). We can get/set MSR in hypervisor through ioctl on vcpufd, or in kernel using instructions rdmsr and wrmsr. To register a syscall handler: lea rdi, [rip+syscall_handler] call set_handler syscall_handler: // handle syscalls! set_handler: mov eax, edi mov rdx, rdi shr rdx, 32 /* input of msr is edx:eax */ mov ecx, 0xc0000082 /* MSR_LSTAR, Long Syscall TARget */ wrmsr ret The magic number 0xc0000082 is the index for MSR, you can find the definitions in Linux source code. After setup, we can invoke syscall instruction and the program will jump to the handler we registered. syscall instruction not only changes rip, but also sets rcx as return address so that kernel knows where to go back after handling syscall, and sets r11 as rflags. It will change two segment registers cs and ss as well, which we will describe in the next section. Switching between kernel and user We also need to register the cs's selector for both kernel and user, via the register MSR we have used before. Here and here describe what does syscall and sysret do in details, respectively. From the pseudo code of sysret you can see it sets attributes of cs and ss explicitly: CS.Selector ← IA32_STAR[63:48]+16; CS.Selector ← CS.Selector OR 3; /* RPL forced to 3 */ /* Set rest of CS to a fixed value */ CS.Base ← 0; /* Flat segment */ CS.Limit ← FFFFFH; /* With 4-KByte granularity, implies a 4-GByte limit */ CS.Type ← 11; /* Execute/read code, accessed */ CS.S ← 1; CS.DPL ← 3; CS.P ← 1; CS.L ← 1; CS.G ← 1; /* 4-KByte granularity */ CPL ← 3; SS.Selector ← (IA32_STAR[63:48]+8) OR 3; /* RPL forced to 3 */ /* Set rest of SS to a fixed value */ SS.Base ← 0; /* Flat segment */ SS.Limit ← FFFFFH; /* With 4-KByte granularity, implies a 4-GByte limit */ SS.Type ← 3; /* Read/write data, accessed */ SS.S ← 1; SS.DPL ← 3; SS.P ← 1; SS.B ← 1; /* 32-bit stack segment*/ SS.G ← 1; /* 4-KByte granularity */ We have to register the value of cs for both kernel and user through MSR: xor rax, rax mov rdx, 0x00200008 mov ecx, 0xc0000081 /* MSR_STAR */ wrmsr The last is set flags mask: mov eax, 0x3f7fd5 xor rdx, rdx mov ecx, 0xc0000084 /* MSR_SYSCALL_MASK */ wrmsr The mask is important, when syscall instruction is invoked, CPU will do: rcx = rip; r11 = rflags; rflags &= ~SYSCALL_MASK; If the mask is not set properly, kernel will inherit the rflags set in user mode, which can cause severely security issues. The full code of registration is: register_syscall: xor rax, rax mov rdx, 0x00200008 mov ecx, 0xc0000081 /* MSR_STAR */ wrmsr mov eax, 0x3f7fd5 xor rdx, rdx mov ecx, 0xc0000084 /* MSR_SYSCALL_MASK */ wrmsr lea rdi, [rip + syscall_handler] mov eax, edi mov rdx, rdi shr rdx, 32 mov ecx, 0xc0000082 /* MSR_LSTAR */ wrmsr Then we can safely use the syscall instruction in user-mode. Now let's implement the syscall_handler: .globl syscall_handler, kernel_stack .extern do_handle_syscall .intel_syntax noprefix kernel_stack: .quad 0 /* initialize it before the first time switching into user-mode */ user_stack: .quad 0 syscall_handler: mov [rip + user_stack], rsp mov rsp, [rip + kernel_stack] /* save non-callee-saved registers */ push rdi push rsi push rdx push rcx push r8 push r9 push r10 push r11 /* the forth argument */ mov rcx, r10 call do_handle_syscall pop r11 pop r10 pop r9 pop r8 pop rcx pop rdx pop rsi pop rdi mov rsp, [rip + user_stack] .byte 0x48 /* REX.W prefix, to indicate sysret is a 64-bit instruction */ sysret Notice that we have to properly push-and-pop not callee-saved registers. The syscall/sysret will not modify the stack pointer rsp, so we have to handle it manually. Hypercall Sometimes our kernel needs to communicate with the hypervisor, this can be done in many ways, in my kernel I use the out/in instructions for hypercalls. We have used the out instruction to simply print a byte to stdout, now we extend it to do more fun things. An in/out instruction contains two arguments, 16-bit dx and 32-bit eax. I use the value of dx for indicating what kind of hypercalls is intended to call, and eax as its argument. I defined these hypercalls: #define HP_NR_MARK 0x8000 #define NR_HP_open (HP_NR_MARK | 0) #define NR_HP_read (HP_NR_MARK | 1) #define NR_HP_write (HP_NR_MARK | 2) #define NR_HP_close (HP_NR_MARK | 3) #define NR_HP_lseek (HP_NR_MARK | 4) #define NR_HP_exit (HP_NR_MARK | 5) #define NR_HP_panic (HP_NR_MARK | 0x7fff) Then modify the hypervisor to not only print bytes when encountering KVM_EXIT_IO: while (1) { ioctl(vm->vcpufd, KVM_RUN, NULL); switch (vm->run->exit_reason) { /* other cases omitted */ case KVM_EXIT_IO: // putchar(*(((char *)vm->run) + vm->run->io.data_offset)); if(vm->run->io.port & HP_NR_MARK) { switch(vm->run->io.port) { case NR_HP_open: hp_handle_open(vm); break; /* other cases omitted */ default: errx(1, "Invalid hypercall"); } else errx(1, "Unhandled I/O port: 0x%x", vm->run->io.port); break; } } Take open as example, I implemented the handler of open hypercall in hypervisor as: (warning: this code lacks security checks? /* hypervisor/hypercall.c */ static void hp_handle_open(VM *vm) { static int ret = 0; if(vm->run->io.direction == KVM_EXIT_IO_OUT) { // out instruction uint32_t offset = *(uint32_t*)((uint8_t*)vm->run + vm->run->io.data_offset); const char *filename = (char*) vm->mem + offset; MAY_INIT_FD_MAP(); // initialize fd_map if it's not initialized int min_fd; for(min_fd = 0; min_fd <= MAX_FD; min_fd++) if(fd_map[min_fd].opening == 0) break; if(min_fd > MAX_FD) ret = -ENFILE; else { int fd = open(filename, O_RDONLY, 0); if(fd < 0) ret = -errno; else { fd_map[min_fd].real_fd = fd; fd_map[min_fd].opening = 1; ret = min_fd; } } } else { // in instruction *(uint32_t*)((uint8_t*)vm->run + vm->run->io.data_offset) = ret; } } In kernel we invoke the open hypercall with: /* kernel/hypercalls/hp_open.c */ int hp_open(uint32_t filename_paddr) { int ret = 0; asm( "mov dx, %[port];" /* hypercall number */ "mov eax, %[data];" "out dx, eax;" /* trigger hypervisor to handle the hypercall */ "in eax, dx;" /* get return value of the hypercall */ "mov %[ret], eax;" : [ret] "=r"(ret) : [port] "r"(NR_HP_open), [data] "r"(filename_paddr) : "rax", "rdx" ); return ret; } Almost done Now you should know all things to implement a simple Linux kernel running under KVM. Some details are worthy to be mentioned during the implementation. execve My kernel is able to execute a simple ELF, to do this you will need knowledge with structure of ELF, which is too complicated to introduce here. You can refer to the source code of Linux for details: linux/fs/binfmt_elf.c#load_elf_binary. memory allocator You will need malloc/free for kernel, try to implement a memory allocator by yourself! paging Kernel has to handle the mmap request from user mode, so you will need to modify the page tables during runtime. Be care of NOT mixing kernel-only addresses with user-accessible addresses. permission checking All arguments passed from user-mode most be carefully checked. I've implemented checking methods in kernel/mm/uaccess.c. Without properly checking, user-mode may be able to do arbitrary read/write on kernel-space, which is a severe security issue. Conclusion This post introduces how to implement a KVM-based hypervisor and a simple Linux kernel, wish it can help you know about KVM and Linux more clearly. I know I've omitted many details here, especially for the kernel part. Since this post is intended to be an introduction of KVM, I think this arrangement is appropriate. If you have any questions or find bugs in my code, leave comments here or file an issue on github. If this post is helpful to you, I'll be very grateful to see 'thanks' on twitter @david942j Source

La multi ani!

La multi ani !

La multi ani !?

Pai eu in exemplul pe care ti l-am dat am folosit NULL AS ColumnName in query pentru a substitui coloanele lipsa, aducand asftel toate tabelele la aceleasi numar de coloane. Sau mai simplu zis, am introdus coloane fictive cu valoarea NULL. Daca dai forma tabelelor (SQL-ul cu create) iti scriu eu un union select. Dar tot sunt de parere ca ai o mare problema de design. Poate daca ne explici ce vrei sa faci, gasim o solutie mai eleganta.

Bemveu fa

Astea se fac sa nu te insele vanzatoare de la magazin cand iti da restul.

Hawkeye Keylogger – Reborn v8: An in-depth campaign analysis July 11, 2018 Office 365 Threat Research in Microsoft 365, Office 365 Advanced Threat Protection, Windows Defender Advanced Threat Protection, Endpoint Security, Threat Protection, Research Much of cybercrime today is fueled by underground markets where malware and cybercriminal services are available for purchase. These markets in the deep web commoditize malware operations. Even novice cybercriminals can buy malware toolkits and other services they might need for malware campaigns: encryption, hosting, antimalware evasion, spamming, and many others. Hawkeye Keylogger is an info-stealing malware that’s being sold as malware-as-a-service. Over the years, the malware authors behind Hawkeye have improved the malware service, adding new capabilities and techniques. It was last used in a high-volume campaign in 2016. This year marked the resurgence of Hawkeye. In April, malware authors started peddling a new version of the malware that they called Hawkeye Keylogger – Reborn v8. Not long after, on April 30, Office 365 Advanced Threat Protection (Office 365 ATP) detected a high-volume campaign that distributed the latest variants of this keylogger. At the onset, Office 365 ATP blocked the email campaign and protected customers, 52% of whom are in the software and tech sector. Companies in the banking (11%), energy (8%), chemical (5%), and automotive (5%) industries are also among the top targets Figure 1. Top industries targeted by the April 2018 Hawkeye campaign Office 365 ATP uses intelligent systems that inspect attachments and links for malicious content to protect customers against threats like Hawkeye in real time. These automated systems include a robust detonation platform, heuristics, and machine learning models. Office 365 ATP uses intelligence from various sensors, including multiple capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP). Windows Defender AV (a component of Windows Defender ATP) detected and blocked the malicious attachments used in the campaign in at least 40 countries. United Arab Emirates accounted for 19% of these file encounters, while the Netherlands (15%), the US (11%), South Africa (6%) and the UK (5%) make the rest of the top 5 countries that saw the lure documents used in the campaign. A combination of generic and heuristic protections in Windows Defender AV (TrojanDownloader:O97M/Donoff, Trojan:Win32/Tiggre!rfn, Trojan:Win32/Bluteal!rfn, VirTool:MSIL/NetInject.A) ensured these threats are blocked in customer environments. Figure 2. Top countries that encountered malicious documents used in the Hawkeye campaign As part of our job to protect customers from malware attacks, Office 365 ATP researchers monitor malware campaigns like Hawkeye and other developments in the cybercriminal landscape. Our in-depth investigation into malware campaigns like Hawkeye and many others adds to the vast threat intelligence we get from the Microsoft Intelligent Security Graph, which enables us to continuously raise the bar in security. Through the Intelligent Security Graph, security technologies in Microsoft 365 share signals and detections, allowing these technologies to automatically update protection and detection mechanisms, as well as orchestrate remediation across Microsoft 365. Figure 3. Microsoft 365 threat protection against Hawkeye Campaign overview Despite its name, Hawkeye Keylogger – Reborn v8 is more than a common keylogger. Over time, its authors have integrated various modules that provide advanced functionalities like stealth and detection evasion, as well as credential theft and more. Malware services like Hawkeye are advertised and sold in the deep web, which requires anonymity networks like Tor to access, etc. Interestingly, the Hawkeye authors advertised their malware and even published tutorial videos on a website on the surface web (that has since been taken down). Even more interesting, based on underground forums, it appears the malware authors have employed intermediary resellers, an example of how cybercriminal underground business models expand and evolve. Our investigation into the April 2018 Hawkeye campaign shows that the cybercriminals have been preparing for the operation since February, when they registered the domains they later used in the campaign. Typical of malware campaigns, the cybercriminals undertook the following steps: Built malware samples and malware configuration files using a malware builder they acquired from the underground Built weaponized documents to be used a social engineering lure (possibly by using another tool bought in the underground) Packed or obfuscated the samples (using a customized open-source packer) Registered domains for delivery of malware Launched a spam campaign (possibly using a paid spam service) to distribute the malware Like other malware toolkits, Hawkeye comes with an admin panel that cybercriminals use to monitor and control the attack. Figure 4: Hawkeye’s admin panel Interestingly, some of the methods used in this Hawkeye campaign are consistent with previous attacks. This suggests that the cybercriminals behind this campaign may be the same group responsible for malware operations that delivered the remote access tool (RAT) Remcos and the info-stealing bot malware Loki. The following methods were used in these campaigns: Multiple documents that create a complicated, multi-stage delivery chain Redirections using shortened bit.ly links Use of malicious macro, VBScript, and PowerShell scripts to run the malware; the Remcos campaign employed an exploit for CVE-2017-0199 but used the same domains Consistent obfuscation technique across multiple samples Point of entry In late April, Office 365 ATP analysts spotted a new spam campaign with the subject line RFQ-GHFD456 ADCO 5647 deadline 7th May carrying a Word document attachment named Scan Copy 001.doc. While the attachment’s file name extension was .doc, it was in fact a malicious Office Open XML format document, which usually uses a .docx file name extension. In total, the campaign used four different subject lines and five attachments. Figure 5: Sample emails used in the Hawkeye campaign Because the attachment contains malicious code, Microsoft Word opens with a security warning. The document uses a common social engineering lure: it displays a fake message and an instruction to “Enable editing” and “Enable content”. Figure 6: The malicious document with social engineering lure The document contains an embedded frame that connects to a remote location using a shortened URL. Figure 7: frame in settings.rels.xml on the document The frame loads an .rtf file from hxxp://bit[.]ly/Loadingwaitplez, which redirects to hxxp://stevemike-fireforce[.]info/work/doc/10.doc. Figure 8: RTF loaded as a frame inside malicious document The RTF has an embedded malicious .xlsx file with macro as an OLE object, which in turn contains a stream named PACKAGE that contains the .xlsx contents. The macro script is mostly obfuscated, but the URL to the malware payload is notably in plaintext. Figure 9: Obfuscated macro entry point De-obfuscating the entire script makes its intention clear. The first section uses PowerShell and the System.Net.WebClient object to download the malware to the path C:\Users\Public\svchost32.exe and execute it. The macro script then terminates both winword.exe and excel.exe. In specific scenarios where Microsoft Word overrides default settings and is running with administrator privileges, the macro can delete Windows Defender AV’s malware definitions. It then changes the registry to disable Microsoft Office’s security warnings and safety features. In summary, the campaign’s delivery comprises of multiple layers of components that aim to evade detection and possibly complicate analysis by researchers. Figure 10: The campaign’s delivery stages The downloaded payload, svchost32.exe, is a .NET assembly named Millionare that is obfuscated using a custom version of ConfuserEx, a well-known open-source .NET obfuscator. Figure 11: Obfuscated .NET assembly Millionare showing some of the scrambled names The obfuscation modifies the .NET assembly’s metadata such that all the class and variable names are non-meaningful and scrambled names in Unicode. This obfuscation causes some analysis tools like .NET Reflector to show some namespaces or classes names as blank, or in some cases, display parts of the code backwards. Figure 12: .NET Reflector presenting the code backwards due to obfuscation Finally, the .NET binary loads an unpacked .NET assembly, which includes DLL files embedded as resources in the portable executable (PE). Figure 13: Loading the unpacked .NET assembly during run-time Malware loader The DLL that initiates the malicious behavior is embedded as a resource in the unpacked .NET assembly. It is loaded in memory using process hollowing, a code injection technique that involves spawning a new instance of a legitimate process and then “hollowing it out”, i.e., replacing the legitimate code with malware. Figure 14: In-memory unpacking of the malware using process hollowing. Unlike previous Hawkeye variants (v7), which loaded the main payload into its own process, the new Hawkeye malware injects its code into MSBuild.exe, RegAsm.exe, and VBC.exe, which are signed executables that ship with .NET framework. This is an attempt to masquerade as a legitimate process. Figure 15: Obfuscated calls using .NET reflection to perform process hollowing injection routine that injects the malware’s main payload into RegAsm.exe Additionally, in the previous version, the process hollowing routine was written in C. In the new version, this routine is completely rewritten as a managed .NET that calls the native Windows API. Figure 16: Process hollowing routine implemented in .NET using native API function calls Malware functionalities The new Hawkeye variants created by the latest version of the malware toolkit have multiple sophisticated functions for information theft and evading detection and analysis. Information theft The main keylogger functionality is implemented using hooks that monitor key presses, as well as mouse clicks and window context, along with clipboard hooks and screenshot capability. It has specific modules for extracting and stealing credentials from the following applications: Beyluxe Messenger Core FTP FileZilla Minecraft (replaced the RuneScape module in previous version) Like many other malware campaigns, it uses the legitimate BrowserPassView and MailPassView tools to dump credentials from the browser and email client. It also has modules for taking screenshots of the desktop, as well as the webcam, if it exists. Notably, the malware has a mechanism to visit certain URLs for click-based monetization. Stealth and anti-analysis On top of the processes hollowing technique, this malware uses other methods for stealth, including alternate data streams that remove mark of the web (MOTW) from the malware’s downloaded files. This malware can be configured to delay execution by any number of seconds, a technique used mainly to avoid detection by various sandboxes. It prevents antivirus software from running using an interesting technique. It adds keys to the registry location HKLM\Software\Windows NT\Current Version\Image File Execution Options and sets the Debugger value for certain processes to rundll32.exe, which prevents execution. It targets the following processes related to antivirus and other security software: AvastSvc.exe AvastUI.exe avcenter.exe avconfig.exe avgcsrvx.exe avgidsagent.exe avgnt.exe avgrsx.exe avguard.exe avgui.exe avgwdsvc.exe avp.exe avscan.exe bdagent.exe ccuac.exe ComboFix.exe egui.exe hijackthis.exe instup.exe keyscrambler.exe mbam.exe mbamgui.exe mbampt.exe mbamscheduler.exe mbamservice.exe MpCmdRun.exe MSASCui.exe MsMpEng.exe msseces.exe rstrui.exe spybotsd.exe wireshark.exe zlclient.exe Further, it blocks access to certain domains that are usually associated with antivirus or security updates. It does this by modifying the HOSTS file. The list of domains to be blocked is determined by the attacker using a config file. This malware protects its own processes. It blocks the command prompt, registry editor, and task manager. It does this by modifying registry keys for local group policy administrative templates. It also constantly checks active windows and renders action buttons unusable if the window title matches “ProcessHacker”, “Process Explorer”, or “Taskmgr”. Meanwhile, it prevents other malware from infecting the machine. It repeatedly scans and removes any new values to certain registry keys, stops associated processes, and deletes related files. Hawkeye attempts to avoid automated analysis. The delay in execution is designed to defeat automated sandbox analysis that allots only a certain time for malware execution and analysis. It likewise attempts to evade manual analysis by monitoring windows and exiting when it finds the following analysis tools: Sandboxie Winsock Packet Editor Pro Wireshark Defending mailboxes, endpoints, and networks against persistent malware campaigns Hawkeye illustrates the continuous evolution of malware in a threat landscape fueled by the cybercriminal underground. Malware services make malware accessible to even unsophisticated operators, while simultaneously making malware more durable with advanced techniques like in-memory unpacking and abuse of .NET’s CLR engine for stealth. In this blog we covered the capabilities of its latest version, Hawkeye Keylogger – Reborn v8, highlighting some of the enhancements from the previous version. Given its history, Hawkeye is likely to release a new version in the future. Organizations should continue educating their employees about spotting and preventing social engineering attacks. After all, Hawkeye’s complicated infection chain begins with a social engineering email and lure document. A security-aware workforce will go a long way in securing networks against attacks. More importantly, securing mailboxes, endpoints, and networks using advanced threat protection technologies can prevent attacks like Hawkeye, other malware operations, and sophisticated cyberattacks. Our in-depth analysis of the latest version and our insight into the cybercriminal operation that drives this development allow us to proactively build robust protections against both known and unknown threats. Office 365 Advanced Threat Protection (Office 365 ATP) protects mailboxes as well as files, online storage, and applications from malware campaigns like Hawkeye. It uses a robust detonation platform, heuristics, and machine learning to inspect attachments and links for malicious content in real-time, ensuring that emails that carry Hawkeye and other threats don’t reach mailboxes and devices. Learn how to add Office 365 ATP to existing Exchange or Office 365 plans. Windows Defender Antivirus (Windows Defender AV) provides an additional layer of protection by detecting malware delivered through email, as well as other infection vectors. Using local and cloud-based machine learning, Windows Defender AV’s next-gen protection can block even new and unknown threats on Windows 10 and Windows 10 in S mode. Additionally, endpoint detection and response (EDR) capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP) expose sophisticated and evasive malicious behavior, such as those used by Hawkeye. Sign up for free Windows Defender ATP trial. Windows Defender ATP’s rich detection libraries are powered by machine learning and allows security operations teams to detect and respond to anomalous attacks in the network. For example, machine learning detection algorithms surface the following alert when Hawkeye uses a malicious PowerShell to download the payload: Figure 16: Windows Defender ATP alert for Hawkeye’s malicious PowerShell component Windows Defender ATP also has behavior-based machine learning algorithms that detect the payload itself: Figure 17: Windows Defender ATP alert for Hawkeye’s payload These security technologies are part of the advanced threat protection solutions in Microsoft 365. Enhanced signal sharing across services in Windows, Office 365, and Enterprise Mobility + Security through the Microsoft Intelligent Security Graph enables the automatic update of protections and orchestration of remediation across Microsoft 365. Office 365 ATP Research Indicators of Compromise (Ioc) Email subject lines {EXT} NEW ORDER ENQUIRY #65563879884210# B/L COPY FOR SHIPMENT Betreff: URGENT ENQ FOR Equipment RFQ-GHFD456 ADCO 5647 deadline 7th May Attachment file names Betreff URGENT ENQ FOR Equipment.doc BILL OF LADING.doc NEW ORDER ENQUIRY #65563879884210#.doc Scan Copy 001.doc Swift Copy.doc Domains lokipanelhostingpanel[.]gq stellarball[.]com stemtopx[.]com stevemike-fireforce[.]info Shortened redirector links hxxp://bit[.]ly/ASD8239ASdmkWi38AS (was also used in a Remcos campaign) hxxp://bit[.l]y/loadingpleaswaitrr hxxp://bit[.l]y/Loadingwaitplez Files (SHA-256) d97f1248061353b15d460eb1a4740d0d61d3f2fcb41aa86ca6b1d0ff6990210a – .eml 23475b23275e1722f545c4403e4aeddf528426fd242e1e5e17726adb67a494e6 – .eml 02070ca81e0415a8df4b468a6f96298460e8b1ab157a8560dcc120b984ba723b – .eml 79712cc97a19ae7e7e2a4b259e1a098a8dd4bb066d409631fb453b5203c1e9fe – .eml 452cc04c8fc7197d50b2333ecc6111b07827051be75eb4380d9f1811fa94cbc2 – .eml 95511672dce0bd95e882d7c851447f16a3488fd19c380c82a30927bac875672a – .eml 1b778e81ee303688c32117c6663494616cec4db13d0dee7694031d77f0487f39 – .eml 12e9b955d76fd0e769335da2487db2e273e9af55203af5421fc6220f3b1f695e – .eml 12f138e5e511f9c75e14b76e0ee1f3c748e842dfb200ac1bfa43d81058a25a28 – .eml 9dfbd57361c36d5e4bda9d442371fbaa6c32ae0e746ebaf59d4ec34d0c429221 – .docx (stage 1) f1b58fd2bc8695effcabe8df9389eaa8c1f51cf4ec38737e4fbc777874b6e752 – .rtf (stage 2) 5ad6cf87dd42622115f33b53523d0a659308abbbe3b48c7400cc51fd081bf4dd – .doc 7db8d0ff64709d864102c7d29a3803a1099851642374a473e492a3bc2f2a7bae – .rtf 01538c304e4ed77239fc4e31fb14c47604a768a7f9a2a0e7368693255b408420 – .rtf d7ea3b7497f00eec39f8950a7f7cf7c340cf9bf0f8c404e9e677e7bf31ffe7be – .vbs ccce59e6335c8cc6adf973406af1edb7dea5d8ded4a956984dff4ae587bcf0a8 – .exe (packed) c73c58933a027725d42a38e92ad9fd3c9bbb1f8a23b3f97a0dd91e49c38a2a43 – .exe (unpacked) *Updated 07/12/18 (Removed statement that Hawkeye Keylogger is also known as iSpy Keylogger Sursa: https://cloudblogs.microsoft.com/microsoftsecure/2018/07/11/hawkeye-keylogger-reborn-v8-an-in-depth-campaign-analysis/