boredhackerblog: November 2022

Introduction:

In some security/malware chat room, someone posted about an ELF backdoor, at the time, I couldn't find much information about it and any related samples or reports. Few weeks ago, I saw similar sample being discussed on twitter, which was found by a researcher in an open directory.

In this post, I just have some notes on my analysis/research of this sample and related samples. This might help with writing a signature or doing further research. I'm just calling this OpenSSL-1.0.0-fipps backdoor since that's what it initially sends to the C2 server and "fipps" has an extra p.

As far as I'm aware, I haven't found similar samples with the searches I've done and I have not seen any samples successfully connect to C2 on any public sandboxes. I was also not able to find any executables for the C2 with some of the yara rules I wrote and queried Hybrid-Analysis for.

Notes:

It's a reverse shell/backdoor. The binary researches out to the C2 IP and Port defined in the binary. You can find C2 IP by just running strings.

Samples:

MD5 hashes:

eb7ba9f7424dffdb7d695b00007a3c6d VT: First Submission 2022-04-21 18:44:09 UTC, submission name: suspicious

97f352e2808c78eef9b31c758ca13032 VT: First Submission 2022-08-26 22:47:54 UTC, submission name: client

3e9ee5982e3054dc76d3ba5cc88ae3de VT: First Submission 2022-11-04 00:18:27 UTC, submission name: client

Sha256 hashes:

8cd16feb7318c0de3027894323a0ccaacb527e071aa4c4b691feb411b6bd0937

40da2329b2b81f237fc30d2274529e6fda4364516b78b4b88659c572fbc4bc02

4e5e42b1acb0c683963caf321167f6985e553af2c70f5b87ec07cc4a8c09b4d8

C2s:

162.220.10.214

107.175.64.203

185.29.10.38

After doing some historic searches, the C2's were running Windows, not that it matters much.

TELFhash for the binaries is: t1afe0d814d67c0dad4ab20c30d4989a94a047eb2688752922ab98d9c1883d917f15cf5f

File command results & diff:

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=16eee120b0a557907a782d1405c8f86415902fa5, stripped

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=2c46d3c40075dc7a193f8041f9458b40fd1f31cf, stripped

BuildID are the same for eb7ba9f7424dffdb7d695b00007a3c6d and 97f352e2808c78eef9b31c758ca13032 and only diff is the IP.

< 00004110: 0000 0000 0000 0000 3130 372e 3137 352e ........107.175.

< 00004120: 3634 2e32 3033 0067 6574 6966 6164 6472 64.203.getifaddr

---

> 00004110: 0000 0000 0000 0000 3136 322e 3232 302e ........162.220.

> 00004120: 3130 2e32 3134 0067 6574 6966 6164 6472 10.214.getifaddr

Not 100% sure about the reason for this and why someone modified just the IP and why it wasn't recompiled.

eb7ba9f7424dffdb7d695b00007a3c6d was the sample being discussed in a chat room, the user mentioned that the file was dropped after log4j exploitation.

The most recent sample 3e9ee5982e3054dc76d3ba5cc88ae3de was found in an open directory. Here's the tweet regarding it: https://twitter.com/r3dbU7z/status/1588337205595951106 In the reply tweet below (https://twitter.com/1ZRR4H/status/1588398704913895425 ) the user mentions finding a webshell as well. Maybe the threat actor is initially gaining access through external web vulns. I'm not really sure.

Finally, there is 97f352e2808c78eef9b31c758ca13032 and I'm not sure where it came from. The sample was discovered after searching for the following yara rule on Hybrid Analysis:

rule elf_backdoor_fipps

{

strings:

$a = "found mac address"

$b = "RecvThread"

$c = "OpenSSL-1.0.0-fipps"

$d = "Disconnected!"

condition:

(all of them) and uint32(0) == 0x464c457f

}

(there is also "dbus-statd" that appears in the all the binaries)

There is also a Suricata signature published by Proofpoint/EmergingThreats that exists:

alert tcp any any -> any 443 (msg:"ET MALWARE Malicious ELF Activity"; dsize:<50; content:"OpenSSL-1.0.0-fipps"; startswith; fast_pattern; reference:md5,eb7ba9f7424dffdb7d695b00007a3c6d; classtype:trojan-activity; sid:2036592; rev:1; metadata:affected_product Mac_OSX, affected_product Linux, attack_target Client_Endpoint, created_at 2022_05_12, deployment Perimeter, former_category MALWARE, signature_severity Major, tag RAT, updated_at 2022_05_12;)

The suricata signature above is for initial connection from the backdoor to the c2 server.

When the sample runs, it prints "!!!Hello World!!!" and the mac address it found, connects to the C2 server, sends OpenSSL-1.0.0-fipps and the mac address.

There also appears to be I guess a heartbeat packet which looks like this:

Processing of commands takes place at FUN_00401f23 (i'm just using names ghidra assigns):

The binary is stripped and I wasn't able to figure out every single function or execute every single function but it has typical backdoor capabilities and it's also able to gather some info and send it back to the C2. There also seems to be encoding of the output (by FUN_00402181 ??) before it gets sent via network.

1: grab user and system info

3: shell?

5: write file?

7: not sure

0xb: delete a file

0xd: directory/file listing?

0xf: not sure

0x11: not sure

0x13: not sure

0x17: seems to return c2 connection info

It does have functions for doing network connections, killing processes, etc...

From doing some testing, the command input that it expects seems to be 16 bytes. The following worked for me for deleting a file:

\x00\x00\x00\x00\x00\x00\x00\x00\x0b\x00 (command) \x05\x00 (input size)\x00\x00\x00\x00delme

0b is the command (byte next to 0b is supposed to the secondary command if that function supports it) and 05 is the number of bytes to read afterwards, delme is 5 bytes.

I'm not sure about the impact of changing other values in that 16 byte input but I know it changes the way the backdoor processes the input & encodes (first 8 bytes).

Conclusion:

It's a weird backdoor that I haven't found much info about or have seen fully run in a sandbox while being connected to its C2.

I assume it's being used after initial access through web/external vulnerability (according to the tweets related to the latest sample, the threat actor had some usernames and active directory info they had taken from an organization they breached) but I'm not sure as there aren't many samples (or reports) I was able to find with the TELFhash and yara rule I made. It's very easy for the threat actor to modify the strings in the binary. I did see some specific assembly instructions that I wrote a yara rules for but they came back with the files that I already had.

Links:

https://www.virustotal.com/gui/file/8cd16feb7318c0de3027894323a0ccaacb527e071aa4c4b691feb411b6bd0937/details

https://www.virustotal.com/gui/file/40da2329b2b81f237fc30d2274529e6fda4364516b78b4b88659c572fbc4bc02/details

https://www.virustotal.com/gui/file/4e5e42b1acb0c683963caf321167f6985e553af2c70f5b87ec07cc4a8c09b4d8/details

https://twitter.com/r3dbU7z/status/1588337205595951106

https://twitter.com/1ZRR4H/status/1588398704913895425

Introduction:

This started with someone asking about EvilProxy and any signatures for detecting it.

EvilProxy is a phishing as a service (PhaaS), which can be used to capture credentials and cookies from a user auth, which also also works with MFA being enabled. It's essentially a reverse proxy that captures information for the attacker when you auth/start a session on a service that's doing reverse proxy for.

More information can be found here: https://resecurity.com/blog/article/evilproxy-phishing-as-a-service-with-mfa-bypass-emerged-in-dark-web

Similar projects include evilnginx, modlishka, and muraena.

Usually for http/https traffic signature, we may want to look for status code, post/get parameters & pattern, URI pattern, JA3/JA3S, cert properties, html properties/body, and etc.

Here's an example for evilnginx:

https://github.com/kgretzky/evilginx2/blob/master/core/certdb.go#L400

https://twitter.com/malwrhunterteam/status/1354039003121647624

There can be multiple types of detections as well. For example, detection of a service by utilizing scanning/scan response (shodan/censys) and detection from traffic monitoring (zeek extracting cert info and logging).

In this post, I'm just documenting just methods and what I've found researching EvilProxy. I don't have anything conclusive and from screenshots/videos the EvilProxy looks pretty thought-out and I'm sure it's easy for the devs to change behavior. They let you customize pretty much everything.

Notes:

Looking at the video shared by Resecurity, I see the following:

subdomain is set to lmo by default.

Stream BotGuard redirects to brave.com by default. Later on there is also redirect to example.com and office.com

URL GET query can have username=email@example.com but that seems optional.

URL with eqp=base64_email_address is also supported.

Some of the interesting IOC's listed by Resecurity are:

147[.]78[.]47[.]250
185[.]158[.]251[.]169
194[.]76[.]226[.]166
msdnmail[.]net
evilproxy[.]pro
top-cyber[.]club
rproxy[.]io
login-live.rproxy[.]io

The other IOC comes from ThreatInsight/Proofpoint posting a domain and attributing it to EvilProxy phishing kit

hxxps://auth[.]royalqueenelizabeth[.]com/?

Status Code:

Searching for some of the IP's on Shodan and viewing history shows this:

Looking at webpage scan runs on Anyrun shows this:

This is what URLScan shows as well:

Maybe we can look for servers being used for EvilProxy phishing sites by looking for "444 Unknown Status Code"?

Censys Query: (services.http.response.status_code:444 and services.http.response.status_reason:"Unknown Status Code") and services.software.vendor=`nginx`

Shodan Query: http.status:444 "Unknown Status Code" "nginx"

URLScan Query: page.status:444 AND server:"nginx"

Shodan & Censys: out of 5 & 4 results, 2 IP's were publicly known for phishing.

URLScan showed a ton of data and it's easy to tell from the domain & subdomain names which sites are phishing:

The searching for 444 approach works fine but it doesn't seem to be too accurate when it comes to Shodan and Censys. It's much more useful when looking at URLScan though.

Also, 444 doesn't show up for everything. It may have shown up for some of the domains due to misconfiguration possibly? i don't know.

Subdomain name:

The other approach for looking for EvilProxy domains could be using subdomain names (with maybe additional queries). This will likely have false positives and since EvilProxy offers a lot of configuration options, if the user changed the default settings, you wouldn't have too much success.

Some of the subdomain names EvilProxy has used are (based on VT & videos): lmo (microsoft), auth, login-live, wwwofc, accounts (google), mso (microsoft), github (github).

URLScan can be queried with: page.domain:(login-live.* OR accounts.* OR lmo.* OR auth.* OR wwwofc.* OR mso.* OR github.*) but github, auth, and accounts might lead to false positives.

This might be much better: page.domain:(login-live.* OR lmo.* OR wwwofc.* OR mso.*)

Crt.sh can also be searched for certs issued for some of the subdomains, however, that may not work very well since it looks like in the past wildcard certs were issued.

URL parameters/pattern:

One of the things we see above (in urlscan screenshot) is and in ThreatInsight/Proofpoint example is question mark '?' at the end of the URL. That could be searched for. Additionally, username= or eqp= can be searched for. Searching for /? and username= will lead to a lot of false positives. The search could be combined with some of the URLScan queries to potentially get less false positives.

URLScan query would look like this: page.url:"/?eqp=" NOT page.domain:ups.com

It kinda shows some malicious sites with some false positives. Also this search doesn't produce many results. At the time of writing, there were only 49 results.

Again, since EvilProxy is customizable, the parameters can be changed by the user.

Redirects:

From the streams feature that was shown in the video, EvilProxy can perform actions such as redirect based on rules regarding the traffic source. Some of the defaults included brave.com, google.com and example.com. I'm sure other configuration settings include more redirections.

Only problem with this is, many sites might be doing these redirects, including other phishing kits so this doesn't mean source site is EvilProxy. The previous query for default subdomains can be combined to potentially get better results.

In URLScan this query provides results for any redirects to brave.com: page.redirected:off-domain AND ("brave.com") AND task.url:(login-live.* OR lmo.* OR wwwofc.* OR mso.*)

HTML Body:

One of the things I noticed while doing the following query: page.redirected:off-domain AND page.domain:(login-live.* OR lmo.* OR wwwofc.* OR mso.*) is that some of the screenshots for malicious websites look like this:

This results from some javascript which can be found here: https://urlscan.io/responses/e85dcff15d140f96a949d9a186c44edb2723e90073bc902d5e278ecad0d1661a/

I didn't spend too much time researching it but it looks like it may be trying to do fingerprinting. Some of the things in the javascript show up here: https://github.com/fingerprintjs/fingerprintjs/blob/master/src/sources/dom_blockers.ts

Searching for javascript code that does fingerprinting in network traffic or on URLScan might be useful for hunting, however, I'd assume other people are using javascript to fingerprint so it might not always be useful.

The code kinda looks like this:

Essentially, it's title Wait... /title, script big_js_block /script, script let randomvar = base64 /script

Regex rule applied to http traffic might be able to find this maybe?

HTTP Requests:

While doing research/queries, I found a website that was not doing any redirection and is possibly EvilProxy (getting 444 on one of the pages related to this).

Traffic to this site shows the following POST request after fingerprinting:

The response looks like this:

Once that's done, a cookie with cookiekey:cookievalue get's added to the session.

There is also a websocket connection/heartbeat, which doesn't happen with real microsoft login page:

The request for sending username/password look identical for the phishing site and normal login site.

websocket, fingerprinting POST, and response with cookies might be something that can be detected on wire if TLS/SSL interception and suricata/zeek monitoring is in place.

Conclusion:

EvilProxy offers a lot of customization so a lot of stuff mentioned above can be modified the by user but some users might just use default settings.

Without a lot of attribution directly to EvilProxy and research out there, a lot of the stuff above is just an educated guess with the information I have available. I could be wrong about a lot of things. These are just notes and not anything conclusive.