(Cooming Soon)

A couple of months ago, I was chatting with a friend about new security technologies. He asked me if I know about any previous work to use eBPF to prevent malicious activities (ergo malware) or at least to detect them.

I heard about eBPF before (as a replacement for Netfilter and such) but never spent a reasonable amount of time studying it. As such, I went down through the rabbit hole to learn a little more.

I was amazed by its capabilities. Below, I'll try to explain as simple as possible what eBPF is and what it can do, along with solid references for those that want to learn more. There's a lot of good information on the internet but I intended to be more generalist and give a light introduction to it.

This post will be updated with more information as soon as possible.

The following topics will be discussed: 1. eBPF brief history 2. eBPF Virtual Machine 3. eBPF program overview 4. eBPF types of programs 4. What are helpers functions? 5. How eBPF is loaded? 6. How can userspace programs interact with eBPF programs 6. eBPF Maps 7. References

eBPF brief history

Back in the '90s, the Berkeley Packet Filter was released by Steve McCanne and Van Jacobson at Lawrence Berkeley Laboratory and its intents is to “provides a raw interface to data link layers in a protocol-independent fashion” and appeared, as usual, as a special device /dev/bpf, allowing raw link-layer packets to be sent and received.

Later on, inspired by BPF, eBPF was introduced in kernel version 3.18, extending the Linux kernel with features capabilities in a similar manner like BPF. But, unlikely BSD, the developer must not be aware of devices and such things. Rather, they will create their code and attach it to the kernel in specifics hook points.

Then, when some sort of event (like a network packet) reaches the system, if there's any BPF program attached to a hook related to that kind of event, the data is “passed” to the program to be processed.

But before we dive little more, we have to understand what is the eBFF Virtual Machine.

eBPF Virtual Machine

eBPF program overview

eBPF types of programs

What are helpers functions?

How eBPF are loaded?

How can userspace programs interact with eBPF programs

eBPF Maps

References

http://www.tcpdump.org/papers/bpf-usenix93.pdf https://sysdig.com/blog/introducing-container-observability-with-ebpf-and-sysdig/ https://blogs.oracle.com/linux/post/bpf-in-depth-building-bpf-programs

Until then.

Until then.

After gathering “all” information that I need, most of the hacks were straightforward metasploit modules and exploits ready to run. I hacked 11 easy machines so far, which isn't' a good number.

Another thing that I noticed is that, so far, most of the machines, when they step up the difficulty level, does this by including some web vulnerabilities.

Since I don't like, nor I'm an expert on webvulns, I'm currently struggling to hack some “not so easy” VMs based on this kind of vulns. Of course I do know about the OWASP guidelines and basic web tests that every analyst must perform.

I'll keep the pace as long as I can. Then, if I got tired I'll switch to the reverse and crackme challenges. It's more fun and well-suited for my skills.

Until next time,

Continuing our analysis of malicious documents, we will now address the step that is known as static analysis . However, before entering this phase, we need to understand which format is used by the documents.

In our case, we are referring to documents used by the Microsoft Office suite, which follow the Compound Document Format (mentioned in the previous post ), in addition to having support for the document architecture known as Object Linking and Embedding (OLE).

The main point of this alphabet soup is: Office documents have the ability, through OLE, to link other documents or objects within themselves. A spreadsheet within a Word document is an example of this. And it is in this structure that the malicious code is inserted, which can be simple embedded executables or even shellcodes.

These codes abuse known flaws in old versions of Microsoft Office (which only adopted a new standard in 2007) to be executed. Once running, they use several other techniques to be able to create or read files, capture user entries, modify other documents or even, in rarer cases, enter the kernel space (from where they can run with more privileges).

Now the question that remains is: how do I preemptively discover that a document is malicious? Unfortunately the answer is not simple and depends on factors that are not necessarily under our control, as we saw in one the first part of this post. Discussing them here would be quite time consuming (and make reading tedious for some). But there is something we can do once we have a suspicious file: a static analysis of it.

The analysis of this type of document has received less attention than it deserves, perhaps because it is not so trivial and does not fit the simple analysis based on hash. In addition, PDF documents are distributed more frequently and easily. In this analysis we will need to perform the following steps:

1. Check the file structure and look for malicious snippets.
2. Identify what type of threat is inserted in the file.
3. Extract the malicious instructions (or part of them).
4. Look for suspicious symbols.
5. Check if they use exploration techniques.
6. Rebuild the executable and analyze it.

To accomplish step 1 we have a few options:

a) Use a sandbox (method used in the first part and which we will ignore); b) Analyze the file structure and search its fields for unexpected data; c) Automatically analyze the file and score it according to the data entered.

Options b) and c) are actually complementary, however, for learning purposes they will be put separately.

I will start presenting OfficeVis, a tool developed by Microsoft for its developers and that will help us in activity “b”. It is able, when loading the files, to separate its fields according to the CDF standard, to show the associated data and to check for inconsistencies.

In addition, there is the ability to search for known exploits, based on CVEs. Once analyzed, it can identify the malicious bytes inserted into the document. As an example, I will use the file that was sent to the clouds in the first part of the post . Below is the image of the result found by the tool:

We are immediately introduced to this set of bytes which, according to the tool, make up a strong candidate for an exploit reported by CVE-2006-6456 .

Once again we have results that give us strong indications but do not give us certainty. The tool reported a few more sets of malicious bytes but was also unsure.

For this reason, I will now introduce another tool: MalOfficeScanner. Developed and presented by Frank Boldewin at Hack.Lu 2009, it presents some very interesting features: scanning for malicious codes (scan); decoding codes through brute force (brute); debugging of codes found with disassembly of them and detection of strings and embedded PE files (debugging); obtaining OLEs, offsets, and VB macros (info); decompression of Office 2007 files for identification and categorization of threats (inflate).

We will focus here on two options: scan and debug. First the scan:

Right from the start we have several function prologue signatures found on certain offset:

What is this “function prologue”? Roughly speaking, the prologue is a programming convention that determines that some instructions must be called in certain order to prepare the stack for use by the function that is starting. This preparation can (and should) keep the “context” of the past function, in case it is necessary to return to it. Later on I will show some examples.

The key point here is: should we have functions in this document? Analyzing the next evidence we found something very interesting:

The tool was able to detect several signatures of a technique that we simply call JMP/CALL/POP. This is one of the best known and most used shellcoding techniques to obtain the effective address from where that piece of code is executing. I encourage you to seek a more “extensive” definition of this technique; worth it.

This time, we have confirmation that a technique that allows us to discover a memory address (and later manipulate it) is being used extensively.

Continuing, we are informed that section signatures exist within the document that identify the existence of possible MZ / PE executables; formats for MS-DOS and Windows executables, respectively:

It is interesting to note that at this very moment the tool is extracting these “executables” from a relative address and creating a separate binary. At the end it performs a summation of all the evidence found, giving different weight to each one of them, and shows us an index:

This rate is very high! Frank himself showed files with a score of 36 points in his presentation. This file is, according to the tool, “very malicious”.

Now let's go to the debug, which will analyze the binary, present it in hexadecimal format and try to extract some valuable information from there:

We are immediately presented with a character string that identifies an “old” function, which according to Microsoft exists only for the purpose of backwards compatibility with old versions of Windows, whose purpose is to run binaries: Winexec . Very convenient, isn't it?

Next is a call to the CreateFile function , which creates files or accesses input/output devices (I/O, for example: hard drives):

The following function (CloseHandle) is related to object handling:

Another interesting function: WriteFile, which similarly to CreateFile, writes to files or I/O devices.

ReadFile: reads files or I/O devices.

SetFilePointer: adjust the pointer to files.

VirtualAlloc: reserves pages at the virtual address as a resource for the running process.

And now, as promised, the binary after being reversed by the tool and with its proper identified mnemonics and indicating the presence of prologues! Following is the assembly code that characterizes the prologue of a function:

Without going too far into the code above, I would like to draw attention to the first 6 lines, which represent the instant that the base addresses are saved and a new stack is created (stack frame). “When” the prologue takes place is irrelevant to this moment in the analysis and varies widely with what we know as calling convention. For the sake of curiosity, I recommend checking the difference of this call between Windows, Linux and OSX.

And finally the raw data that, after “mapped” by MalOfficeScan, presents the string “this program must be run under Win32”, indicating that an executable must be run on the Windows operating system that supports programmed binaries for the 32-bit architecture (the encompassing a wide spectrum of machines):

I think we got enough evidence that the document is not to be trusted! In this post, we walk through steps 1 to 5. In a way, we also performed step 6, but in an automated way. For the next post we will go deeper into the binary in search of more clues and other techniques used by those who wrote this artifact.

Until then, Unfortunately, the original document was lost before I complete the complete analysis of this malicious doc

Bibliographic references: Check the original post linked before

I recently had the opportunity to get my hands on a .doc file that was sent to me and that had been categorized using an antivirus heuristic as an infected file.

After being informed of the possible infection, the person who gave me the file simply said that other AVs did not identify it as being a malicious file and questioned the first analysis, implying that he believed that the file would not actually be infected.

So I asked that person what he did to feel so safe to say that the document was not really infected. To my surprise I received an image of the result of an antivirus (AV) cloud:

Apparently the fact that only one AV solution detected the file as malicious did not seem to bother the person. The questions that came to mind then were:

Do other cloud and sandbox solutions have similar results?

Do they have the capacity to analyze documents of this type (Composite Document File V2, CDF)?

Do the tools warn you when they are unable to parse the document or simply check for a known hash base?

To answer the first question, I went after other cloud and sandbox solutions to see how they behaved.

It is possible to notice that more than one solution has detected a threat and a coincidence between them; the categorization of the file: MW97: ShellCode. We will use this information later.

Unfortunately we don't know the engine version of these solutions.

It is relevant to note that the opensource solution brought two important pieces of information (if they are true):

1. PUA (Possibly Unwanted Application): This does not necessarily mean that the file is infected but that it has characteristics that can be used for “good” or “evil”. In this case, he identified a possible packer.

2. BorlandDelphi-2 : Is this an indication that possible malicious code was built using Borland Delphi? We will try to capture this information later.

Now let's see another result:

This time we have a more “correct” result: 13 embedded codes were found . Among them, it is worth mentioning the calls to the following “routines”: KERNEL32, GetCommanLineA, CreateFileA, CreateWindowsExA. It is worth mentioning that this sandbox is specialized in analyzing malicious documents:

“An advanced malware detection engine designed to decrypt and extract malicious executables from common document formats such as MS Office Word, Powerpoint, Excel, Access, or Adobe PDF documents. ViCheck will detect the majority of embedded executables in documents as well as common exploits which download malware from the internet. ”

And to finish another analysis:

Now things are interesting! Another sandbox specializing in documents also found embedded codes and some of the so-called concurrences. In addition, executable files were downloaded .

I believe the answer to 1st question was answered: clouds and sandboxes do not always show similar results. I uploaded the document (file 1) in at least five more sandboxes. Unfortunately they were inconsistent. And it was not just a difference in nomenclature between them. Some actually said there was nothing in the file!

“Who's right?” it is a difficult question to be answered by the “ordinary” user. If we upload it to a cloud full of AVs, we have no way of knowing which ones actually performed the most appropriate verification because the method is almost never clear. Many AVs only check for file signatures in their database. Others have heuristic analysis. While others analyze the structure of the documents.

Now we come to the answer to the second question: only some clouds and sanboxes really have the capacity to analyze CDFs .

And now? How much can a person or company trust in these analyzes? Many companies that own these clouds are not responsible for these results (at least not in their “free” version). And several are simply unclear about their limitations and also do not warn the user, which is the answer to our third question. Just check the different sandboxes returned by google (and indicated in the references).

So… what is the way out???

Well… nothing better than the old “hands on”. In the next post we will crawl into a static analysis of the document.

Until then,

Bibliographic references: Check the original post linked before

As a way to study and revisit most of the skills required to pentest real environments, I started a couple of weeks ago to crack some Hackthebox virtual machines (VM). At first, I was wondering if this was the right way to learn something new.

I must say that I'm not disappointed since most of the box is set in such a way that you need an overall knowledge of the Operating System/Technology that you're targeting. In addition, after you exaustly enumerated the box you “must” know a little bit about the service, protocol or whatever you want to attack.

I know that's an obvious statement 'cause this the way that most real pentest works but it's a relief to know that such platform exist. For those that do not have the time or resources to create it's own environment and labs, Hackthebox is awesome. For those that chose to pay for the VIP pass, many more retired VM's are available

The experience

HTB overall user experience was smooth, at least for me. It's portal has an intuitive GUI, menus and options. No complains about that. The only downside is the slow and sometimes unstable connection if you're on the free access. But that's expected for this kind of service with a lot of users massively brute forcing, scanning, crawling and forgering requests to HTBoxes.

To generate the credentials and connect to the HTB network itself is super easy, at least for those with some experience with VPN's.

Choosing the VM and cracking it

For those that never cracked a box or are rusty about pentest, my recommendation is to start with a already cracked box. HTB have a list of retired machines that are available to VIP members but a few of them are available, for a limited period of time, to non-VIP members. Most of those VMs have walktroughs that, after the retirement, can be found on forums, blogs, youtube and may help you if you get stuck on some stage of the pentest.

But try to not rely too much on it. Try it yourself. Many times I found myself stuck on some stages and reading/watching a walktrough just to, later on, get the feeling that I already knew what is necessary to do (because I have the knowledge) but failed to “think out of the box”. Sometimes that kind of mindset comes easier…sometimes just don’t. That’s why you have to develop your own methodology, refine it and use it until stucks in your mind.

In future posts I hope to write a little bit about some of the retired VMs and what interesting finds I had.