Re: [Full-disclosure] Linux - Indicators of compromise
On Fri, Jul 27, 2012 at 3:17 PM, Scott Solmonson wrote: > > Funny, I now want to watch Goldeneye for some reason... Funnier is now I want to watch Dumb and Dumber for obvious reason. > > > Everything you mention are parts of critical infrastructure. > Any organization/nation that claims to have its shit together will > have triple-redundancy, with complete isolation, and optimally > geographical dispersion in place, for said industries. > > Read again what I said: Triple redundancy? Is many company not even have single redundancy. You read too much sci-fi is please stop spread false information on list. List is filled with too many is noobs look to learn, not hear nonsense. Amazon, Twitter, Citibank, BofA and is many others all went down is this past week. All is companies has more money than God and is has competent CERTIFIED staff. Yet is they could not even is keep site up. Maybe is since you can, you can become CTO of is any one of these companies yes. > Your example of critical infrastructure confirms this. > It's better for banking transactions to no be made, versus for them to > go to the wrong account with the wrong amount. > It's better for a doctor to potentially have to make a quick judgement > call, versus giving the wrong procedure to the wrong patient. > It's better for the power plant to go down versus overspinning the > turbines, or shutting off the reactor cooling, and exploding or > melting down. Is better for banking transactions not to be made? Is this same for NASDAQ as this is transaction. No is better for business to CONTINUE - this is the C in BC (Business *CONTINUITY*). Transactions is can be audited on the fly. Doctor make wrong call? Speak and Spell. Is no one say anything about Doctor. Doctor would be too late. Go back and read is what was written. "if the patient alert system is affected" If patient cannot call Doctor or Nurse because help button is tampered with: Goodbye you are the weakest link" Exploding or melting down? Maybe perhaps is you watch too many time Die Hard. In is real environment, turbines and is other HMIs can be addressed by is taking *only* is that turbine and baselining-shifting-outsourcing-outpulsing power to other turbines *without* taking out the mid-west. Perhaps you is go back to work in real environment then come and try and is to test MusntLive. Is your comment show many much immaturity. Is MusntLive now pray your bosses not see these posts. > It's better for the airplanes to have to circle for a bit more versus > sending two on to the same runway at the same time. > etc. > etc. > etc Really? Is not better to send them to another *open* runaway versus is has them circle skies burning fuel, jamming up skies? *is grab popcorn - like DUmb and Dumber stupid movie* ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Thu, Jul 26, 2012 at 6:07 AM, Григорий Братислава wrote: > > Is first MustnLive watch really good movie and is use > quote from is movie: Funny, I now want to watch Goldeneye for some reason... > MusntLive is show you how you fail across many 'vertical' industries. Everything you mention are parts of critical infrastructure. Any organization/nation that claims to have its shit together will have triple-redundancy, with complete isolation, and optimally geographical dispersion in place, for said industries. Read again what I said: >> Once data integrity has been compromised, service downtime is almost always >> the lesser cost. Your example of critical infrastructure confirms this. It's better for banking transactions to no be made, versus for them to go to the wrong account with the wrong amount. It's better for a doctor to potentially have to make a quick judgement call, versus giving the wrong procedure to the wrong patient. It's better for the power plant to go down versus overspinning the turbines, or shutting off the reactor cooling, and exploding or melting down. It's better for the airplanes to have to circle for a bit more versus sending two on to the same runway at the same time. etc. etc. etc -SS -- NUNQUAM NON PARATUS ☤ INCITATUS ÆTERNUS ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
> I can't tell if I'm being trolled or not... Good question. >> Is I am on your network, good luck is find me especially in is post >> exploitation as I am is liable to float around is piggyback from one >> machine is to the next. You can is assume all you want about port >> security in is in fact, utterly worthless in post exploitation as is >> likely I am not even in your physical network. Please is go back to >> CCNA studies and is stop bastardize is something you know a >> ''modicum'' of is about. You fail is off jump with word 'assume' > > Whatever layer-2 feats you've performed or will continue to perform, > you're still very trackable and monitoring/blocking you at layer-3 is > trivial. Assuming it's not a troll, my suspicion is that it's common where Musntlive comes from to use unmanaged switches at the distribution level. I think he has a great point in that case - if you can't associate MAC's with ports and hence physical connections, you do indeed have a problem. And to cut off any rebuttal from Musntlive, yes I am fully aware of how easy it is to spoof MAC addresses. However, if you want your packets on the network, the switch is going to be aware of that your MAC is coming from a particular system (again, assuming managed switches and a one to one relationship of servers to switch ports). If you have a way around that, I suspect you'll have a great talk for Defcon next year. In this mess of emails, I somehow completely lost the context of how we went from a question on being able to analyze a Linux system to determine if it's compromised to arguing about whether we can track back an attacker sending (malicious?) broadcast packets on a network to a specific server. Jerry ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
I can't tell if I'm being trolled or not... Inlined- On Wed, Jul 25, 2012 at 7:04 AM, Григорий Братислава wrote: > > Is I am on your network, good luck is find me especially in is post > exploitation as I am is liable to float around is piggyback from one > machine is to the next. You can is assume all you want about port > security in is in fact, utterly worthless in post exploitation as is > likely I am not even in your physical network. Please is go back to > CCNA studies and is stop bastardize is something you know a > ''modicum'' of is about. You fail is off jump with word 'assume' Whatever layer-2 feats you've performed or will continue to perform, you're still very trackable and monitoring/blocking you at layer-3 is trivial. > So let us is go back to the beginning since you is fail to understand. > Pay is close attention for you is not learn this with Lammle. > > 1) MusntLive is perform remote exploit and is get on your machine > 2) MusntLive exploits is "other" machines and send broadcast via > spoofing on "OTHER" compromised machines > 3) MusntLive is listen for broadcast on any compromised machine Remote-to-machine or remote-to-network? Ultimately I can just say it again: Whatever layer-2 feats you've performed or continue to perform, you're still very trackable and monitoring/blocking you at layer-3 is trivial. > You is expect to track me how? Everyone is listen. Is you can go > narrow down who is broadcast. Even turn of port! I am is still listen > and is will still start again. What is it you is think you will do? > Shut down all ports everywhere? Is maybe BCP filter? URPF? Is you > think so, you is definitely need lay off Lammle and is read > Oppenheimer, Baker, and is too many others you is obviously not ready > for. You've figured it out- tap-port the entire switch's traffic, and then once you've got what you need, shut down every port. Once data integrity has been compromised, service downtime is almost always the lesser cost. -- NUNQUAM NON PARATUS ☤ INCITATUS ÆTERNUS ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Thu, Jul 26, 2012 at 9:40 AM, wrote: > But unfortunately, you're right - most places have screwed up their DR > planning > and can't shut down. They've also screwed up their network config so it > isn't trivial > to track down which port a problem attacker is on. (And yes, tracking down a > miscreant at level 2/3 *is* trivial if your network is in fact properly > designed > and managed) Once upon is time people cry-- "no more free bugs" and is now MusntLive chant-- "no more is free security schooling!" ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Thu, 26 Jul 2012 09:07:33 -0400, ÐÑигоÑий ÐÑаÑиÑлава said: > Really? Shut down is entire racks? Because you will have > backup/standby entire 42Us? If you can't shut down the entire rack, you've screwed up your DR and business continuity planning. This isn't just a problem for large sites - I've seen lots of places claim "We can't take 3 hours of downtime to patch/upgrade/test/whatever because everything is on that one server". And my response has always been "And what were you planning to do if you blew out a power supply or a system board and had a 3-hour outage?". But unfortunately, you're right - most places have screwed up their DR planning and can't shut down. They've also screwed up their network config so it isn't trivial to track down which port a problem attacker is on. (And yes, tracking down a miscreant at level 2/3 *is* trivial if your network is in fact properly designed and managed) pgpsU2t8vxHRK.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Wed, Jul 25, 2012 at 3:36 PM, Scott Solmonson wrote:
> I can't tell if I'm being trolled or not...
>
Inline is MusntLive's comments! MusntLive is now give you guys is some
free training on is Incident Response and is Forensics and is
CCD{A,P,E}. Is first MustnLive watch really good movie and is use
quote from is movie:
"Hello Scott. I want to play a game. So far what loosely could be
called security, you have made your postings rambling nonsense which
would make organizations like ISC2 and ISACA proud. Ramblings which
will shall now be shredded to bit. I call you unworthy of responding
to my posts. Of the chances you have been given, you have cherished
none. The packets in these posts are filled with information.
Information you do not seem to grasp. If you do not change your ways
and heed the information given to you, organizations like ISC2 and
ISACA will continue to pollute your brain. Your brain will close.
Think of this information like a venus flytrap. What you are looking
at right now is the information that can set you free. Do not heed
this information and security nonsense will swallow you whole.
Consuming your body into a herd of wandering security zombies. Each
with a title: CISSP, CISM, CISA, CEH." --- MusntLive is play security
Jigsaw
> Whatever layer-2 feats you've performed or will continue to perform,
> you're still very trackable and monitoring/blocking you at layer-3 is
> trivial.
Is so very trivial is how so many fester in networks globally
undetected. Yes MusntLive understand you are karate kid.
> Remote-to-machine or remote-to-network? Ultimately I can just say it
> again: Whatever layer-2 feats you've performed or continue to perform,
> you're still very trackable and monitoring/blocking you at layer-3 is
> trivial.
Monitoring and tracking on is any layer is trivial? How many is
enterprise networks is has you worked on.?
> You've figured it out- tap-port the entire switch's traffic, and then
> once you've got what you need, shut down every port. Once data
> integrity has been compromised, service downtime is almost always the
> lesser cost.
MusntLive is show you how you fail across many 'vertical' industries.
BANKING
---
Sample Bank's {N,S}OC is running 10 42Us is filled with servers. Seven
42Us is filled with 1U servers. One 42U is Oracle M9000, one 42U is
has QFX3000M fully populated (6,144 10GbE ports) one 42U is has take
your pick, EX, Cat, BigIron. MusntLive is compromise a 1U somewhere on
a 42U. All racks is run the bank's business. MusntLive broadcast to
all on network.
You call Gigamon and buy your G-TAP to watch me. Once you "got what
you need, you shut down every port" is you say. Really? Shut all ports
down? "Integrity is compromised, service downtime" (DR/BCP nonsense).
Now what? You still is not find me.
Because each 1U is kind of is new, you now need to figure out is what
happened where. Each 1U is has half TB data. You now need image these
1Us for your investigation. Is remember is bank you need report to
clients as is they have credit card transaction. Forget is fact your
bank is will lose more money more you have downtime. Have you is done
your homework. What is your estimated MTTR? (CCDP term for you is
learn this afternoon).
I think Scott you work on network where is has at max 5 Cat 2950s as
is your statement not valid even is remotely in the banking industry.
HEALTHCARE
---
Sample Hospitals {S,N}OC is has 1 42U. Is five racks has 48 port
switch, 10 has 2U servers and is each server has 4 network ports. You
has firewalls, SSL appliances, DB and is special server to link to
room so is when patients ring emergency bell, nurses come running is
like flock of seagull (and I ran, ran so far away). You will shut down
all is switchport here now too also?
MusntLive is not go further into your nonsense reply.
SCADA
---
Sample hydroelectrical plant...
Really? Shut down all ports?
Sample gas plant...
Really? Shut down all ports?
MIL/GOV
---
Sample USCYBERCOM
Really? Shut down is Pentagon?
Sample IC.FBI.GOV
Really? Shut down is entire racks? Because you will have
backup/standby entire 42Us?
MusntLive chuckle. Is you has not even answer "how you will find me"
is you really think pulling plug is save you. Lets make believe is
your plan work. You pull plug on all ports (shut them down is what you
say). Now comes fun stuff!
You call up DigitalIntelligence. Even in is small hospital you is has
to image 10 drives (small disks remember MusntLive is say half TB).
5TB to image because since is your rack is infected, you must image to
retain forensically sound is evidence. After you call the company
DigitalIntelligence, they have is fastest network based imaging
system. 6.6Gb a minute.
MusntLive make believe DigitalIntelligence make delivery in 1hr and
you can is start imaging! How much downtime is passed before your
imaging is done? Don't worry you can is tell patients, surgeons, ER
room: "se
Re: [Full-disclosure] Linux - Indicators of compromise
On Wed, Jul 25, 2012 at 7:04 AM, Giles Coochey wrote: > On 18/07/2012 13:10, Григорий Братислава wrote: > If you broadcast using a MAC address you are on the same subnet, layer 2. > > On a wired network I don't really care whether you spoofed your mac address > or not, you still registered the mac address on the switch, and I can see > what port you connected to. Then I just need to follow the cable to find > you. > > In any case, this is an internal intrusion or post-exploitation issue we're > talking about, not an external one, assuming the layer-2 environment has a > modicum of protection. MusntLive is now beg of you is to allow me to is join your groupstudy! MusntLive is live on the edge of assumption! In is case of internal/post-exploitation is reality of matter is you will not find me. You can is assume you will but we all is know where assume lead (http://www.youtube.com/watch?v=6hrLj8QEAgI) Is I am on your network, good luck is find me especially in is post exploitation as I am is liable to float around is piggyback from one machine is to the next. You can is assume all you want about port security in is in fact, utterly worthless in post exploitation as is likely I am not even in your physical network. Please is go back to CCNA studies and is stop bastardize is something you know a ''modicum'' of is about. You fail is off jump with word 'assume' So let us is go back to the beginning since you is fail to understand. Pay is close attention for you is not learn this with Lammle. 1) MusntLive is perform remote exploit and is get on your machine 2) MusntLive exploits is "other" machines and send broadcast via spoofing on "OTHER" compromised machines 3) MusntLive is listen for broadcast on any compromised machine You is expect to track me how? Everyone is listen. Is you can go narrow down who is broadcast. Even turn of port! I am is still listen and is will still start again. What is it you is think you will do? Shut down all ports everywhere? Is maybe BCP filter? URPF? Is you think so, you is definitely need lay off Lammle and is read Oppenheimer, Baker, and is too many others you is obviously not ready for. MusntLive like this game. Now you come back and is counter, then I come is back and is counter you to smitheruskis! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On 18/07/2012 13:10, Григорий Братислава wrote: On Wed, Jul 18, 2012 at 3:18 AM, Giles Coochey wrote: Is you have much more to worry than is ICMP/GRE tunnels. Is I send to Broadcast and I am is on your network, how do you is plan to pinpoint who I am when is everyone see broadcast By your source MAC address -- Regards, Really? I am so glad your company is has you for security. So a message is broadcast to everyone. Everyone on say is /21 is listen and you is going to pick me out, out of is everyone else who is listen? Genius! Nobel Prize A+++ number one is seller! Is not only is idea you mention genius, is good that no one can is change their MAC address! Is proof MusntLive must go back is study CISSP and now is CCNA If you broadcast using a MAC address you are on the same subnet, layer 2. On a wired network I don't really care whether you spoofed your mac address or not, you still registered the mac address on the switch, and I can see what port you connected to. Then I just need to follow the cable to find you. In any case, this is an internal intrusion or post-exploitation issue we're talking about, not an external one, assuming the layer-2 environment has a modicum of protection. -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
It seems that English isn't your first language, so no problem with the confusion- "don't isolate, monitor spread tactics, perceptually contain and then analyse." Isolation in an INFOSEC sense means actual measures to stop actual actions. The short version looks like "we've got all the information we need, it's time to seal this bitch in a cage". Before that point is reached, the most important thing is to monitor without damage to determine behaviors and tactics, hence "perceptually contain"; in order to anticipate future actions. Imagine thousands of VMs spun up on a fully simulated IP space with a full suite honeypot profile- Let the cows roam, see where they find grass... Your analysis of my explanation: > 1) Let hacker run amok so you can see them is run amok > 2) Once hacker is run amok, steal your bread and is butter, wipe your > systems, restore > 3) Go back and is learn why they steal and delete. 1) an enemy can not be countered unless it can be understood 2) that bread and butter was put there, by me, on purpose 3) simple knowledge is power, motivational knowledge is godlike 4) ??? 5) profit! -- NUNQUAM NON PARATUS ☤ INCITATUS ÆTERNUS On Thu, Jul 19, 2012 at 6:18 AM, Григорий Братислава wrote: > On Wed, Jul 18, 2012 at 12:20 PM, Scott Solmonson wrote: >> Shortcutting other responses- > >> 2) assume the worst, don't isolate, monitor spread tactics, >> perceptually contain and then analyse. > > This is make sense! Do not isolate. Let hacker run rampant in is your > network. Because if they is damage your network in is process of not > isolating them, is ok if they is steal and delete. You get to see what > is they stole after is gone, and after they is wipe your system. This > is good advice yes, help test your BC/DR! MusntLive like absurd and > obscure approach! > >> Endgame is always close the hole, restore the data, learn from your >> mistakes that allowed it to happen :) > > MusntLive is love your advice! > > According to you: > > 1) Let hacker run amok so you can see them is run amok > 2) Once hacker is run amok, steal your bread and is butter, wipe your > systems, restore > 3) Go back and is learn why they steal and delete. > > MusntLive think answer for #3) is logic one: "Idiot admin allowed is > this to happen" ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
http://www.rootkit.nl/projects/rootkit_hunter.html/ 2012/7/18 Григорий Братислава > On Wed, Jul 18, 2012 at 8:30 AM, alex wrote: > > Source MAC faking would result in switchport shutdown in some > environments. > > Further you cannot communicate with outside world using broadcasts. > > ICMP payloads is quite common and hard to detect. > > > > Me study CISSP, too. Already CCNA Security. CCNA not worth the money. > Better get CISA/CISM. > > > > > > You miss point. If I sent data to broadcast, original poster is say: > "I will know who you are via MAC address" to which I say: "You is need > to go back to Cisco bootcamp" Everyone is receive broadcast, no way > for him to detect who I am since I am is not alone in receiving the > broadcast. Needle in is haystack. > > Second, ICMP tunneling, GRE tunneling is too much trouble. Advanced > Persistent Threats as defined by (is now give North Korean title to > him) Super Grand Master of the Internet Universe Richard Bejtlich as > advanced and is persistent. But is also stupid and lazy. Will not > waste time on this is vector. Will use SSL and HTTP to is stay under > radar. > > Attacker >>> Own is your data >>> post data in $WBEDIR >>> visit > $WEBDIR using proxy [small packets] > > Is how else can attacker download 867 terabytes of data > ( > http://www.eddupdate.com/2012/02/cyberthieves-stole-867-terabytes-in-2011.html > )? > You believe attackers is using FTP, ICMP, GRE tunnels? No. Too noisy > is this. Better to visit website like everyone else use proxy of > another country, this is country take blame. > > MusntLive >>> use is never use 213.24.76.77 address >>> use proxy > 210.75.193.49 >>> download data \ > Supreme Grand Master of Internet Universe >>> analyze >>> see proxy > >>> chant APT APT APT >>> See I told you is China \ > Fox News >>> report on Chinese threat \ > MusntLive >>> facepalm at report and go back is drink Stoli > > CISA/CISM is have nothing on InfoSecInstitute! > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- Disclaimer: This communication may contain confidential, proprietary or legally privileged information. It is intended only for the person(s) to whom it is addressed. If you are not an intended recipient, you may not use, read, retransmit, disseminate or take any action in reliance upon it. Please notify the sender that you have received it in error and immediately delete the entire communication, including any attachments. I do not encrypt and cannot ensure the confidentiality or integrity of external e-mail communications and, therefore, I cannot be responsible for any unauthorized access, disclosure, use or tampering that may occur during transmission. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. I accept no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On 17/07/2012 18:58, Григорий Братислава wrote: On Mon, Jul 16, 2012 at 10:35 AM, Giles Coochey wrote: On 16/07/2012 14:48, Gary Baribault wrote: I suggest one of the first answers was the good one, intercept the traffic routed to the internet with TCPDump. Filter out the normal traffic and see what's left. All compromised systems talk to the Internet to dump data or route spam. Be patient, some systems talk all the time, some once an hour .. but you will find some unexplained traffic. Once you do find that you're infected, don't bother cleaning up the system, format and restore the data! Is you have much more to worry than is ICMP/GRE tunnels. Is I send to Broadcast and I am is on your network, how do you is plan to pinpoint who I am when is everyone see broadcast By your source MAC address -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Wed, Jul 18, 2012 at 12:20 PM, Scott Solmonson wrote: > Shortcutting other responses- > 2) assume the worst, don't isolate, monitor spread tactics, > perceptually contain and then analyse. This is make sense! Do not isolate. Let hacker run rampant in is your network. Because if they is damage your network in is process of not isolating them, is ok if they is steal and delete. You get to see what is they stole after is gone, and after they is wipe your system. This is good advice yes, help test your BC/DR! MusntLive like absurd and obscure approach! > Endgame is always close the hole, restore the data, learn from your > mistakes that allowed it to happen :) MusntLive is love your advice! According to you: 1) Let hacker run amok so you can see them is run amok 2) Once hacker is run amok, steal your bread and is butter, wipe your systems, restore 3) Go back and is learn why they steal and delete. MusntLive think answer for #3) is logic one: "Idiot admin allowed is this to happen" ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
Shortcutting other responses- A suspect node that you want to keep live can only be treated in two ways: 1) if you need to know who is behind the shenanigans, you monitor net traffic and isolate/simulate reach and then do what you can to get what you need. 2) assume the worst, don't isolate, monitor spread tactics, perceptually contain and then analyse. Live on-box analysis is useless in every case, and you need to think forensics. Disconnect, dump, analyse- but only after you've got what you really need. Endgame is always close the hole, restore the data, learn from your mistakes that allowed it to happen :) -- NUNQUAM NON PARATUS ☤ INCITATUS ÆTERNUS On Sat, Jul 14, 2012 at 5:46 AM, Ali Varshovi wrote: > Greetings FD, > > Does anyone have any guidelines/useful material on analysis logs of a Linux > machine to detect signs of compromise? The data collection piece is not a > challenge as a lot of useful information can be captured using commands and > some scripts. I'm wondering if there is any systematic approach to analyze > the collected logs? Most of the materials I've seen are more aligned to > malware and rootkit detection which is not the only concern apparently. > > Thanks, > Ali > . > - > Sent from my BlackBerry device > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
I wasn't initially, but that's where the discussion is taking me. I was thinking of collecting local logs from a Linux box and analyze them to determine if its been compromised or not. I understand a hybrid approach should be taken, including pattern detection to capture known malware/backdoors and a behavioral analysis to tag any abnormal behavior. Michael mentioned a very true and good point that theoretically logs and behavior of a compromised system cannot be trusted. Other folks, also pointed that a data exfilteration usually follows a compromise and can be considered as a shared pattern for majority of attacks (I want to add command/control traffic myself). Friends, is that a good summary of a high level approach? Cheers, Ali . - Sent from my BlackBerry device -Original Message- From: Benji Date: Tue, 17 Jul 2012 00:31:12 To: Cc: Subject: Re: [Full-disclosure] Linux - Indicators of compromise SO you're talking about making a baseline? On Mon, Jul 16, 2012 at 7:52 PM, Ali Varshovi wrote: > Hello everybody and thank you for your useful comments. > > Now I'm thinking that we need a comparison base or normal behavior profile to > be able to detect any deviations or abnormal/suspicious activity. While some > known patterns of behaviors are useful to detect malware or backdoors we > still need that normal profile to detect 0-day or APT style intrusions. Isn't > that the same idea from early days of intrusion detection research (anomaly > detection approach)? Or maybe I'm off track. > > Thoughts? > > --Original Message-- > To: full-disclosure@lists.grok.org.uk > Subject: Linux - Indicators of compromise > Sent: Jul 14, 2012 8:46 AM > > Greetings FD, > > Does anyone have any guidelines/useful material on analysis logs of a Linux > machine to detect signs of compromise? The data collection piece is not a > challenge as a lot of useful information can be captured using commands and > some scripts. I'm wondering if there is any systematic approach to analyze > the collected logs? Most of the materials I've seen are more aligned to > malware and rootkit detection which is not the only concern apparently. > > Thanks, > > Ali > . > - > Sent from my BlackBerry device > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
Hello Ali. Is your question about investigating a set of servers you suspect may be infected, or setting up a steady state monitoring strategy to alert when/if a host is compromised? Regards, Jerry On Jul 14, 2012, at 8:46 AM, "Ali Varshovi " wrote: > Greetings FD, > > Does anyone have any guidelines/useful material on analysis logs of a Linux > machine to detect signs of compromise? The data collection piece is not a > challenge as a lot of useful information can be captured using commands and > some scripts. I'm wondering if there is any systematic approach to analyze > the collected logs? Most of the materials I've seen are more aligned to > malware and rootkit detection which is not the only concern apparently. > > Thanks, > Ali > . > - > Sent from my BlackBerry device > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
Hi Jerry, I want to do the analysis on servers/systems that are suspected to be infected. Thanks, Ali . - Sent from my BlackBerry device -Original Message- From: Jerry Bell Date: Tue, 17 Jul 2012 00:02:29 To: Cc: Subject: Re: [Full-disclosure] Linux - Indicators of compromise Hello Ali. Is your question about investigating a set of servers you suspect may be infected, or setting up a steady state monitoring strategy to alert when/if a host is compromised? Regards, Jerry On Jul 14, 2012, at 8:46 AM, "Ali Varshovi " wrote: > Greetings FD, > > Does anyone have any guidelines/useful material on analysis logs of a Linux > machine to detect signs of compromise? The data collection piece is not a > challenge as a lot of useful information can be captured using commands and > some scripts. I'm wondering if there is any systematic approach to analyze > the collected logs? Most of the materials I've seen are more aligned to > malware and rootkit detection which is not the only concern apparently. > > Thanks, > Ali > . > - > Sent from my BlackBerry device > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Wed, Jul 18, 2012 at 8:30 AM, alex wrote: > Source MAC faking would result in switchport shutdown in some environments. > Further you cannot communicate with outside world using broadcasts. > ICMP payloads is quite common and hard to detect. > > Me study CISSP, too. Already CCNA Security. CCNA not worth the money. Better > get CISA/CISM. > > You miss point. If I sent data to broadcast, original poster is say: "I will know who you are via MAC address" to which I say: "You is need to go back to Cisco bootcamp" Everyone is receive broadcast, no way for him to detect who I am since I am is not alone in receiving the broadcast. Needle in is haystack. Second, ICMP tunneling, GRE tunneling is too much trouble. Advanced Persistent Threats as defined by (is now give North Korean title to him) Super Grand Master of the Internet Universe Richard Bejtlich as advanced and is persistent. But is also stupid and lazy. Will not waste time on this is vector. Will use SSL and HTTP to is stay under radar. Attacker >>> Own is your data >>> post data in $WBEDIR >>> visit $WEBDIR using proxy [small packets] Is how else can attacker download 867 terabytes of data (http://www.eddupdate.com/2012/02/cyberthieves-stole-867-terabytes-in-2011.html)? You believe attackers is using FTP, ICMP, GRE tunnels? No. Too noisy is this. Better to visit website like everyone else use proxy of another country, this is country take blame. MusntLive >>> use is never use 213.24.76.77 address >>> use proxy 210.75.193.49 >>> download data \ Supreme Grand Master of Internet Universe >>> analyze >>> see proxy >>> chant APT APT APT >>> See I told you is China \ Fox News >>> report on Chinese threat \ MusntLive >>> facepalm at report and go back is drink Stoli CISA/CISM is have nothing on InfoSecInstitute! ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Wed, Jul 18, 2012 at 3:18 AM, Giles Coochey wrote: >> Is you have much more to worry than is ICMP/GRE tunnels. Is I send to >> Broadcast and I am is on your network, how do you is plan to pinpoint >> who I am when is everyone see broadcast > > By your source MAC address > > > -- > Regards, Really? I am so glad your company is has you for security. So a message is broadcast to everyone. Everyone on say is /21 is listen and you is going to pick me out, out of is everyone else who is listen? Genius! Nobel Prize A+++ number one is seller! Is not only is idea you mention genius, is good that no one can is change their MAC address! Is proof MusntLive must go back is study CISSP and now is CCNA ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Mon, Jul 16, 2012 at 10:35 AM, Giles Coochey wrote: > On 16/07/2012 14:48, Gary Baribault wrote: > > I suggest one of the first answers was the good one, intercept the traffic > routed to the internet with TCPDump. Filter out the normal traffic and see > what's left. All compromised systems talk to the Internet to dump data or > route spam. Be patient, some systems talk all the time, some once an hour .. > but you will find some unexplained traffic. Once you do find that you're > infected, don't bother cleaning up the system, format and restore the data! > Is you have much more to worry than is ICMP/GRE tunnels. Is I send to Broadcast and I am is on your network, how do you is plan to pinpoint who I am when is everyone see broadcast ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On 16/07/2012 14:48, Gary Baribault wrote: I suggest one of the first answers was the good one, intercept the traffic routed to the internet with TCPDump. Filter out the normal traffic and see what's left. All compromised systems talk to the Internet to dump data or route spam. Be patient, some systems talk all the time, some once an hour .. but you will find some unexplained traffic. Once you do find that you're infected, don't bother cleaning up the system, format and restore the data! Gary Baribault Courriel:g...@baribault.net GPG Key: 0x685430d1 Signature: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1 +1, but note you cannot trust tcpdump on the compromised system, even if the md5 matches the kernel might screen the packets you're looking for. Run tcpdump on a trusted system that has a copy of the traffic from the switchport that your suspect system (e.g. Cisco SPAN or rSPAN). Otherwise, if your router supports a similar feature (or you have a router that supports tcpdump, then you can check there. Note that the traffic could be encapsulated in another protocol. ICMP echo / reply payloads have been used in the past as covert communication channels, as has IP protocol 41 (IPv6 encapsulation over IPv4) and IP protocol 47 (GRE). -- Regards, Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Mon, Jul 16, 2012 at 11:52 AM, Ali Varshovi wrote: > > I'm thinking that we need a comparison base or normal behavior profile to be > able to detect any deviations or abnormal/suspicious activity. While some > known patterns of behaviors are useful to detect malware or backdoors we > still need that normal profile to detect 0-day or APT style intrusions. Isn't > that the same idea from early days of intrusion detection research (anomaly > detection approach)? yes, also called: Anomaly Detection Anomaly-Based Intrusion Detection System Outlier Detection Behavior Analysis and other things i've forgotten... ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
SO you're talking about making a baseline? On Mon, Jul 16, 2012 at 7:52 PM, Ali Varshovi wrote: > Hello everybody and thank you for your useful comments. > > Now I'm thinking that we need a comparison base or normal behavior profile to > be able to detect any deviations or abnormal/suspicious activity. While some > known patterns of behaviors are useful to detect malware or backdoors we > still need that normal profile to detect 0-day or APT style intrusions. Isn't > that the same idea from early days of intrusion detection research (anomaly > detection approach)? Or maybe I'm off track. > > Thoughts? > > --Original Message-- > To: full-disclosure@lists.grok.org.uk > Subject: Linux - Indicators of compromise > Sent: Jul 14, 2012 8:46 AM > > Greetings FD, > > Does anyone have any guidelines/useful material on analysis logs of a Linux > machine to detect signs of compromise? The data collection piece is not a > challenge as a lot of useful information can be captured using commands and > some scripts. I'm wondering if there is any systematic approach to analyze > the collected logs? Most of the materials I've seen are more aligned to > malware and rootkit detection which is not the only concern apparently. > > Thanks, > > Ali > . > - > Sent from my BlackBerry device > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
Hello everybody and thank you for your useful comments. Now I'm thinking that we need a comparison base or normal behavior profile to be able to detect any deviations or abnormal/suspicious activity. While some known patterns of behaviors are useful to detect malware or backdoors we still need that normal profile to detect 0-day or APT style intrusions. Isn't that the same idea from early days of intrusion detection research (anomaly detection approach)? Or maybe I'm off track. Thoughts? --Original Message-- To: full-disclosure@lists.grok.org.uk Subject: Linux - Indicators of compromise Sent: Jul 14, 2012 8:46 AM Greetings FD, Does anyone have any guidelines/useful material on analysis logs of a Linux machine to detect signs of compromise? The data collection piece is not a challenge as a lot of useful information can be captured using commands and some scripts. I'm wondering if there is any systematic approach to analyze the collected logs? Most of the materials I've seen are more aligned to malware and rootkit detection which is not the only concern apparently. Thanks, Ali . - Sent from my BlackBerry device ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Mon, Jul 16, 2012 at 10:59 AM, Григорий Братислава wrote: > ... > Is in my experience is that I place two folders in directory in is > root folder called /root/MilaKunisLeakedPhotos/ and > /root/OlgaKurlyenko/ is when I see is accessed. Then I know is my > machine compromised. Everyone is want see Olga and Mila there are honey tokens, and there are *honey* tokens. Григорий Братислава doing it right! ;P ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Sat, Jul 14, 2012 at 8:46 AM, Ali Varshovi wrote: > Greetings FD, > > Does anyone have any guidelines/useful material on analysis logs of a Linux > machine to detect signs of compromise? The data collection piece is not a > challenge as a lot of useful information can be captured using commands and > some scripts. I'm wondering if there is any systematic approach to analyze > the collected logs? Most of the materials I've seen are more aligned to > malware and rootkit detection which is not the only concern apparently. > > Thanks, > Ali Is in my experience is that I place two folders in directory in is root folder called /root/MilaKunisLeakedPhotos/ and /root/OlgaKurlyenko/ is when I see is accessed. Then I know is my machine compromised. Everyone is want see Olga and Mila ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Sat, 14 Jul 2012 12:46:50 + "Ali Varshovi " wrote: > Does anyone have any guidelines/useful material on analysis logs > of a Linux machine to detect signs of compromise? The data > collection piece is not a challenge as a lot of useful information > can be captured using commands and some scripts. I'm wondering if > there is any systematic approach to analyze the collected logs? > Most of the materials I've seen are more aligned to malware and > rootkit detection which is not the only concern apparently. Hi Ali, I'd say send log to another machine, use a "checksumator" (like tripwire), store its computation files on an external storage device and when you check the system with it, boot it on a liveCD. And as G.Baribault says, each compromised system tries to store its findings elsewhere on the Internet (often encrypted these days), so a fine traffic analyzer would be a good thing; but is there a very good one working out of the box, I don't know!? (beware it can be very disk space greedy). JY -- < Overfiend> well, excellent. I get to tear someone a new asshole. -- in #debian-devel ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
Thanks Feighen. I had to say that I'm looking for solutions/guidelines that help in doing the analysis in a short period of time or a narrow shot of the system state. Any thoughts? Ali . - Sent from my BlackBerry device -Original Message- From: Feighen Oosterbroek Date: Mon, 16 Jul 2012 09:26:05 To: Subject: Re: [Full-disclosure] Linux - Indicators of compromise Hey there are programs that can help to analyse log files. Logwatch comes to mind. There are possibly others. I suppose you could write a script to check file permissions and ownership changes over time, which could be a starting point for more in-depth checks Thanks and kind regards Feighen On 14 July 2012 14:46, Ali Varshovi mailto:ali.varsh...@hotmail.com> > wrote: Greetings FD, Does anyone have any guidelines/useful material on analysis logs of a Linux machine to detect signs of compromise? The data collection piece is not a challenge as a lot of useful information can be captured using commands and some scripts. I'm wondering if there is any systematic approach to analyze the collected logs? Most of the materials I've seen are more aligned to malware and rootkit detection which is not the only concern apparently. Thanks, Ali . - Sent from my BlackBerry device ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
" All compromised systems talk to the Internet to dump data or route spam." yup, this is 1000% true and utterly foolproof. On Mon, Jul 16, 2012 at 2:48 PM, Gary Baribault wrote: > I suggest one of the first answers was the good one, intercept the traffic > routed to the internet with TCPDump. Filter out the normal traffic and see > what's left. All compromised systems talk to the Internet to dump data or > route spam. Be patient, some systems talk all the time, some once an hour .. > but you will find some unexplained traffic. Once you do find that you're > infected, don't bother cleaning up the system, format and restore the data! > > Gary Baribault > Courriel: g...@baribault.net > GPG Key: 0x685430d1 > Signature: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1 > > On 07/16/2012 09:40 AM, valdis.kletni...@vt.edu wrote: > > On Sat, 14 Jul 2012 12:46:50 -, "Ali Varshovi " said: > > Most of the materials I've seen are more aligned to malware and rootkit > detection which is not the only concern apparently. > > It's hard to say what else to check without knowing what other concerns > you're checking for, and what data sources are available (I'm thinking about > auditd and friends, but there's other data sources as well). > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
I suggest one of the first answers was the good one, intercept the traffic routed to the internet with TCPDump. Filter out the normal traffic and see what's left. All compromised systems talk to the Internet to dump data or route spam. Be patient, some systems talk all the time, some once an hour .. but you will find some unexplained traffic. Once you do find that you're infected, don't bother cleaning up the system, format and restore the data! Gary Baribault Courriel: g...@baribault.net GPG Key: 0x685430d1 Signature: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1 On 07/16/2012 09:40 AM, valdis.kletni...@vt.edu wrote: > On Sat, 14 Jul 2012 12:46:50 -, "Ali Varshovi " said: >> Most of the materials I've seen are more aligned to malware and rootkit >> detection which is not the only concern apparently. > It's hard to say what else to check without knowing what other concerns > you're checking for, and what data sources are available (I'm thinking about > auditd and friends, but there's other data sources as well). > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
On Sat, 14 Jul 2012 12:46:50 -, "Ali Varshovi " said: > Most of the materials I've seen are more aligned to malware and rootkit > detection which is not the only concern apparently. It's hard to say what else to check without knowing what other concerns you're checking for, and what data sources are available (I'm thinking about auditd and friends, but there's other data sources as well). pgpHTMmfWUjpc.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Linux - Indicators of compromise
> Greetings FD, Hi > Does anyone have any guidelines/useful material on analysis logs of a > Linux machine to detect signs of compromise? First thing: You can NOT surely determine if a machine is compromised within the machine itself. Once a machine is compromised it can (theoretical) react to all your approach to detect it and manipulate the output of your tools. If there is something compromised there is a high chance that it has to communicate to somebody. So you could dump the network traffic on your router or add an (transparent) networklogger between your machine and the router. Another way would be shutting down the machine an analyzing it with an live-cd. But there is not a general way to go sure, its compromised or not. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Linux - Indicators of compromise
Greetings FD, Does anyone have any guidelines/useful material on analysis logs of a Linux machine to detect signs of compromise? The data collection piece is not a challenge as a lot of useful information can be captured using commands and some scripts. I'm wondering if there is any systematic approach to analyze the collected logs? Most of the materials I've seen are more aligned to malware and rootkit detection which is not the only concern apparently. Thanks, Ali . - Sent from my BlackBerry device ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
