Tag Archives: forensics

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 AnalyzerA 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:

Analyzing auth.log
Analyzing secure logs
Dumping & Analyzing wtmp files

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:

AbuseIPDB Bulk Checker result

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.

Generate Memory Dump from .vmss file using vmss2core

Previously, I’ve encountered a problem where I’m unable to copy the .vmem file for further analysis.

So, the next alternative way that we can do is to use .vmss file & convert it into .vmem file. .vmss is a Virtual machine suspend file.

To start convert it, first you need to download vmss2core tool here – https://flings.vmware.com/vmss2core

Next, open your cmd and enter cmd as below:

F:\Tools> .\vmss2core-sb-8456865.exe -W 'F:\INC\<REDACTED>\<REDACTED>.vmss'
vmss2core version 8456865 Copyright (C) 1998-2017 VMware, Inc. All rights reserved.
region[0]: start=0 end=c0000000.
region[1]: start=100000000 end=240000000.
Cannot translate linear address 0.
... 10 MBs written.
... 20 MBs written.
<snip>
... 8180 MBs written.
... 8190 MBs written.
Finished writing core.

After it finished, it will create a file named memory.vmem.

There you have it. So you can start doing your memory analysis using volatility if you want.

For example, here we’ll be using volatility in order to find out the profile for which .vmem is created.

$ python vol.py -f memory.dmp imageinfo
Volatility Foundation Volatility Framework 2.6.1
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win2008R2SP1x64_24000, Win2008R2SP1x64_23418, Win2008R2SP1x64, Win7SP1x64_24000, Win7SP1x64_23418
                     AS Layer1 : WindowsAMD64PagedMemory (Kernel AS)
                     AS Layer2 : VirtualBoxCoreDumpElf64 (Unnamed AS)
                     AS Layer3 : FileAddressSpace (/home/memory.dmp)
                      PAE type : No PAE
                           DTB : 0x187000L
                          KDBG : 0xf800028530a0L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0xfffff80002854d00L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2019-12-23 17:42:50 UTC+0000
     Image local date and time : 2019-12-23 11:42:50 -0600