Tag Archives: bash

Break-In Analyzer – Quickly analyze auth.log, secure, utmp & wtmp logs for possible SSH break-in attempts

Recently, I encountered incident where several hosts been infected by < █████████ >. So, to investigate this incident, we received bunch of logs to be analyze; mostly Linux related logs.

I’ve been thinking.. What if the host has been successfully brute-forced? How can we identify it?

In Linux, there are several logs that we can refer that contains authentication logs for both successful or failed logins, and authentication processes. Location & names of the logs varies; depending on system type. For Debian/Ubuntu, the logs located at /var/log/auth.log. For Redhat/CentOS, the logs located at /var/log/secure.

There are 2 more logs that we can refer;
– /var/log/utmp: current login state by user.
– /var/log/wtmp: record of each user login/logout.

So, what if we write a script to quickly go thru those mentioned logs & identify the culprits? Probably we can find out if our host has been successfully brute-forced.

Introducing.. Break-In Analyzer – A script that analyze the log files /var/log/auth.log (for Debian based systems), /var/log/secure (for RHEL based systems), utmp/wtmp for possible SSH break-in attempts. – https://github.com/zam89/Break-In-Analyzer

Here are some screenshot of the script in action:

The output result will be written into text file; stored into folder named output. Inside the folder will contains file named:
– auth_output.log
– secure_output.log
– utmp_output.log
– wtmp_output.log

So, you must been wondering; how can I validate these IPs? whether they are harmless or not? Well, to do that, we can use AbuseIPDB to quickly see each of IP reputation; either they’re clean or has been reported due to malicious activity.

In this example, I’m using AbuseIPDB Bulk Checker from – https://github.com/AdmiralSYN-ACKbar/bulkcheck. This tool can perform bulk checking of IPs towards AbuseIPDB website. *Just a side notes: it require API key from AbuseIPDb. You can get it for free by registering on the website. Its limited to 1000 request/IPs per day.

So, I’m checking 203 IPs that we got from Break-In Analyzer script output (after removing duplicated using Excels) on AbuseIPDB if there is any records for those IPs. After the check completed, the result shows something like this:

If you filter out by abuseConfidenceScore (removing score 0), you’ll see there are 3 IPs that having kinda high confidence score. The higher the score, the more chances the IP marked as malicious – meaning that the IP has been reported multiple times related to malicious activities.

Next, we cross check with our Break-In Analyzer outputs to see where did these IPs located on the logs. Or you can cross check directly with your logs. To do that, run command as below:

$ grep --perl-regexp "110.93.200.118" --color=always --only-matching --recursive * | sort | uniq --count | sort --numeric --reverse

This command is basically searching where the IP “110.93.200.118” located/contains inside the log. If you run the command, you’ll see output as below:

Now we know that the IP “110.93.200.118” is contains inside wtmp dump log:
– node2/output/wtmpdump_output.txt
– node1/output/wtmpdump_output.txt

and also inside tools output:
– node2/output/output_node2.txt
– node1/output/output_node1.txt

If we go search inside the wtmp dump log for that IP “110.93.200.118“, we found that the IP has been accessing the system since Feb 2016… hmm.. 🤦

cat node2/output/wtmpdump_output.txt | grep 110.93.200.118 --color=always

This may indicate that the attacker has been leveraging the host for very long time.

Next step is probably to search what the IP or the account “portaladmin-ts” is doing inside the host.

Hunting for possible attacker Cobalt-Strike infra

Leave a reply

Recently, we have an incident where suspicious traffic was observed related to external C2. Initial finding found that this IP 172.241.27.17 (172.241.24.0/21) resolved to
atakai[-]technologies[.]host; according to pDNS in Virustotal [1].

So, further digging on this IP found it has port 50050 open. Based on Recorded Future threat analysis report & Cobalt Strike Team Server Population Study, it mentioned that default port for Cobalt Strike controller is on port 50050.

So, I asked to myself. What if the neighboring IPs were also been setup for Cobalt Strike infrastructure? So I decided to go on this journey…

First, we know that the IP range is 172.241.24.0/21. By using this tool, we can convert CIDR notation to a range of IP addresses.

The result, we have 2048 addresses; IP address range between 172.241.24.0-172.241.31.255.

Next, we using online tool named Reverse IP & DNS API from WhoisXML API. Function of this tools is to reveals all domains that share an IP address. Example as below:

To use this tools, we need to buy credit to leverage its API. As for free account, you only have 100 credit to be use on Domain Research Suite tools. But on this case, we need around 2050 credit. Based on their website, 1000 DRS credits = $19.00. So.. yeah..

After you have enough credit, you can use the script as below:

#!/bin/bash

url="https://reverse-ip.whoisxmlapi.com/api/v1?apiKey=whoisxml_apikey&ip="

for i in $(cat ip.txt); do
	content="$(curl -s "$url$i")"
	echo "$content" >> output.txt
done

Remember to put your API key into the script. It will basically produce result into “output.txt“.

After that, import you result into Excel. Then, we sort and select possible domains from the output based on domain naming convention; e.g. atakai, amatai, amamai:

Now we have possible suspected IPs & domains. To further digging, we’ll leverage Shodan.io to see what are the open port available for those IPs.

To use it, we’ll using script as below:

$ curl -s https://api.shodan.io/shodan/host/{172.241.27.17,172.241.27.44,172.241.27.62,172.241.27.65,172.241.27.66,172.241.27.68,172.241.27.72,172.241.27.225,172.241.29.155,172.241.29.156,172.241.29.157}?key=shodan_apikey | jq -r '. | "IP: \(.ip_str) Ports: \(.ports)"'

The output should be like this:

Now we know 7/11 (no pun intended) IPs been observed by Shodan having port 50050 opened. This indicate that this set of IPs possibly used part of Cobalt Strike infra.

Next step is we can search for date registration for each domain from Whois data. But I’m too lazy to continue this. Also I’ve encountered where several Whois provider giving different info regarding of domain registration date. So yeah, maybe I’ll update next time when I’m free 😉

Check bulk IP for reverse DNS (rDNS)

Leave a reply

Recently I’ve encounter list of IPs that are related to CoinHive. So I want to check for domains that tied to these IPs. We can do that by using dig command to perform reverse DNS (rDNS).

Reverse DNS (rDNS) is a method of resolving an IP address into domain name, just as the domain name system (DNS) resolves domain names into associated IP addresses.

I found this script at this site:

#!/bin/bash

for item
    do
        domain=$(dig -x "$item"  +short)
        if [ -n "$domain"  ] ;
            then
            echo "$item" - "$domain"
        else
            echo "$item" result is NULL
        fi
    done

Just save this code above in your Linux/*nix machine, and run this command as below:

[email protected]:~# cat ip.txt | xargs bash reverse_dns

The result should be like this:

Flatten a Nested Directory & File Hierarchy from Command Line of OS X

Leave a reply

Lets say you have this kind of file/folder structure:

master folder ---- folder1 ---- image1.jpg
               |            |
               |            |-- image2.jpg
               |
               |
               |-- folder2 ---- image1.jpg
               |            |
               |            |-- image2.jpg
               |
               |-- etc.

You can take all the *.jpg file or any file type, and move it into one single/master folder.
Here are the command to use:

cd <master_directory> <-- master/top folder where all the file are located inside it
find * -type f -print0 | xargs -0 -I%%% mv -n %%% ../<new_directory> <-- "new destination folder"

Shell script fails: Syntax error: “(” unexpected

Leave a reply

There’s one time I encountered this error when executing a bash code/script:

install.sh: Syntax error: "(" unexpected

The script does not begin with a shebang line, so the kernel executes it with /bin/sh. On Ubuntu, /bin/sh is dash, a shell designed for fast startup and execution with only standard features. When dash reaches the line, it sees a syntax error: that parenthesis doesn’t mean anything to it in context.

Since dash (like all other shells) is an interpreter, it won’t complain until the execution reaches the problematic line. So even if the script successfully started at some point in your testing, it would have aborted once the problematic line was reached.

The shebang line must be the very first thing in the file. Since you use bash features, the first line of the file must be #!/bin/bash or #!/usr/bin/env bash.

Credit:
http://unix.stackexchange.com/questions/45781/shell-script-fails-syntax-error-unexpected

khairulazam.net

Just my simple blog.

Tag Archives: bash

Break-In Analyzer – Quickly analyze auth.log, secure, utmp & wtmp logs for possible SSH break-in attempts

Like this:

Hunting for possible attacker Cobalt-Strike infra

Like this:

Check bulk IP for reverse DNS (rDNS)

Like this:

Flatten a Nested Directory & File Hierarchy from Command Line of OS X

Like this:

Shell script fails: Syntax error: “(” unexpected

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: