LinuxQuestions.org - Real Forensics Case

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Real Forensics Case (https://www.linuxquestions.org/questions/linux-security-4/real-forensics-case-4175435351/)

Quote:

Originally Posted by Linux_Kidd (Post 4822192)

exactly what i said, i need to go check if IDS can alert on SS #'s.

and i'll say it again, a good C2 doesnt put files on the system. do you have forensics training or background ??

You didn't say good, you said odd. Still, a good/stealthy C2 wouldn't even use IRC. An good attacker who cares about stealth also wouldn't be launching SSH dictionary attacks from the victim to any computer it can find on the Internet. Those IoCs are way more obvious than putting files on a box. There is nothing odd/unusual about either of those; they're very common. But I would agree it would be odd if the attacker went through great lengths to remain hidden, yet was using something obvious like IRC as a C2...

Yes, I have a degree in InfoSec, and have gone through SANS GCIA, GREM, and GCFA (not the new revamped course yet :( ). I do intrusion analysis, but mostly involving Windows victims.

fair enough.

i've been doing hands-on InfoSec for last ~15yrs, been an active CISSP for 10yrs (and have numerous other certs), and have taken x-country flights to see local LE serve search warrant and seize all the computer gear in a building so that I could image stuff and analyze it. you may have your view of things, i have mine. thanks for your feedback.

LK

hey unSpawn, do you go by unspawn on ubuntuforums.org ?

I do. BTW feel free to PM or email me that kind of question OK? I mean it doesn't really add to the thread IMHO...

Quote:

Originally Posted by unSpawn (Post 4823784)

I do. BTW feel free to PM or email me that kind of question OK? I mean it doesn't really add to the thread IMHO...

ah, i see you posted over there about the infection i see now (found it via a gool search, etc), but you posted back in 2010 in response to another user asking about the same infection i see. check there on feb 11 2010, its about "ZeuL's Connect Back Backdoor" perl script.

OK. Found the thread. (Seems I've been there longer than I thought I'd been.) I don't know if you regard this thread as casual banter (please don't) or some sort of web log (go here) or if you have problems formulating questions because I still don't have a clue what I can help you with. The Perl script is just collateral, the thread showed the infection vector for that case and as always users blame software instead of their own lack of admin skills, proper hardening, regular auditing etc, etc. In contrast your victim machine, asserting it actually is subject to industry regulations, should show the necessary audit trail details to confirm its usage (if any), right?

so, this script named "a" on my infected system is used to do SSH scanning, but what is the odd echo in bold? i am guessing that echo's stuff back to another process, one that may be a IRC connection ??

Code:

[root@xyz .fresh]# more a



#!/bin/bash



if [ $# != 1 ]; then



        echo " usage: $0 <b class>"



        exit;



fi



 



rm -rf scan.log mfu.txt 1>/dev/null 2>/dev/null



echo -e "                \033[1;33m\033[1;32m  FRESH \033[1;33m\033[0m"



././pscan2 $1 22



 



sleep 10



mv scan.log bios.txt



oopsnr2=`grep -c . bios.txt`



echo -e "**  \033[1;33m          ... incepem ...    \033[0m  **"



export PATH=.:$PATH



hald



rm -rf scan.log mfu.txt 1>/dev/null 2>/dev/null



echo "##        asta a fost, baga clasa urmatoare        ##"

Just color coding. What forensics field / niche did you specialize in for the past years if I may ask? The text is Romanian BTW.

i know what the text is (thanks to gool), but it translates to English oddly, so i would need interpreter for meaning.

i dont specialize in forensics, i am trained in forensics, imaging, CoC, Encase, sleuthkit, bt5, etc etc. forensics is just one of my hats. i deal with many OS'. i specialize in keeping bad guys out.

thanks btw for the color, i forgot about that.

Quote:

Originally Posted by Linux_Kidd (Post 4826208)

i am guessing that echo's stuff back to another process

No, just stdout.

hmmmm, i wonder though if this script was being C2'd through a shovel via IRC connection? attacker had ssh access and was seen connected for about 13hrs during one of the sessions. the infection kit looks automated so i am not 100% confident that there was a body behind the ssh sessions. i myself am not skilled enough to decode the hex of ELF.

Are you the only person analyzing this server?
Is there a time line of events?
Was correlation done with adjacent servers?
Are there any binaries, scripts, etc, etc found?
Do foreign objects, log excerpts, shell history, etc, etc, actually support your assumption of a C&C?

I'm asking because if you don't want to share cold hard facts that's fine but this thread can not continue to exist on unsubstantial "tweets" alone.

1. there were many hands on this box before i got to it.
2. yes, i have a detailed timeline of events gathered from numerous logs and filesystem info, from firewall changes which open ssh to the public, to a uid being compromised from ssh dictionary attack, to the uid history of the attacker. attacker used "history -c" so not too much is there.
3. adjacent servers were under same ingress ssh dictionary attack (as seen by IDs logs) my system was the only one compromised.
4. binaries and scripts were indeed found (klogd ELF, hald ELF, pscan2 ELF, and scripts "start", "a", etc etc). all were created inside of /tmp/.ICE-unix dir.
5. yes, IRC channels existed (as seen in IDS logs), and the historical data i find on some of the script coding indicates a IRC back connect for either monitoring the infection, or for C2. the IRC used went to Undernet (one of a few Undernet servers listed in the script files).

there's a piece i am still trying to figure out. there was a UDP port-0 egress flood going on during the outage. the dst IP was in LACNIC so its not clear to me if the LACNIC IP was a target of UDP flood, or if my customer was the target because the flood took down the firewalls. initial incident response folks found a PID and PPID via lsof that were causing the UDP flood and then killed them. the cwd of these PID's were in the /tmp/.ICE-unix dir where the infection was.

i cant post too much data at this time, its a active case and legal on several fronts are involved.

Quote: