2/ After starting the ELF binary (a reduced version is publicly available on GitHub [2]), the login credentials are printed out (username: manjusaka, PW: b3e..), and the port (3200) on which the panel is accessible.
3/ The password is different for each instance of manjusaka.
This mechanism prevents the use of default passwords in case scanners would find the login panel.
4/ However, if the IP address from the panel is visited without specifying the port, the instance automatically redirects to microsoft.com - another protection against automated scanner.
5/ But beware, it's trivial to change these default values via command line parameters on startup.
6/ After logging in to the panel, we can create a new project.
7/ The implants of the different projects uses a different URL to connect to the C2 server.
The routing ID "c15.." is used within the URL from the GET request. The pooling frequency is super high - in the free version the latency cannot be adjusted.
8/ The URL "/general/favicon.png" was mentioned in the Talos blog [1], but this URL (/general/) is only used if no project is defined.
9/ We can create implants for Windows and Linux.
The encryption key does not matter in this version because an implant with an encryption key and one without one have identical hash sums.
10/ Whereby already various AV manufacturers recognize the implant from this version.
11/ In the screenshot below, two systems have reported to our C2 instance (a Windows and a Linux machine).
Only one infected host can be selected at a time in the workbench because the selection unlocks further possibilities to interact with the infected machine.
12/ After selecting an infected host, among other things, a live terminal can be opened. Direct commands can be issued on the host via this terminal.
Limitedly, the shell also works for Windows systems, but passget did not work on either platform.
13/ The file browser works on Windows as it does on Linux.
14/ We can also upload files directly to the infected machines.
The freely available version of manjusaka has no persistence mechanism (neither on Win nor on Linux), but with the upload functionality, we could load a binary to the different startup locations.
15/ manjusaka creates a SQLite database named nps.db at the first startup:
$ file nps.db
nps.db: SQLite 3.x database, last written using SQLite version 3036000
16/ This database contains information about the infected hosts and could be interesting to evaluate after the seizure of a C2 instance by LEA.
17/ Last but not least, the Shodan favicon search from the panel currently returns no hits (http.favicon.hash:cbfb102cebf1f72f195697293f138128).
18/ As Talos mentions in the blog post, this freely available version is probably only a teaser of the original software but already potent enough to perform actual attacks.
1/ We recently had an interesting #Azure case where the TA, instead of creating a new Inbox Rule, added email addresses of interest to the list of blocked senders and domains.
The incoming emails will get flagged as spam and moved to the Junk email folder. 📂
🧵
2/ Here is a screenshot from Outlook web access
(the view might differ, as, for example, here on the screenshot from the theitbros [1])
1/ Customer receives an email from a network monitoring device that a host is supposedly infected with a #CoinMiner. The Task Manager on the said system shows the following screenshot 🤕.
A story of an unpatched system, incorrect scoping, and 🍀. 🧵
1/ I used #AutoRuns v14.09 (GUI) in my lab setup but noticed that it failed to find (or display) the malware in the Startup folder, although the file is there (screenshot below).
I checked back and forth, searched manually for the file, and restarted the OS and AutoRuns.
🧵
2/ With #Velociraptor, I ran the hunt Sysinternals.Autoruns, and with the CLI version of AutoRuns, the malware is found in the Startup folder.
3/ The same for the #Velociraptor hunt Sys.StartupItems.
1/ Real-World #PingCastle Finding #13: Allow log on locally
➡️ Domain Users are eligible to log into DC's 🤯🙈
"When you grant an account the Allow logon locally right, you are allowing that account to log on locally to all domain controllers in the domain." [1]
"If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges." [1]
3/ I encountered this finding several times in our AD assessments, so you better check your settings in your domain right now (better safe than sorry 🔒).