Hello Reader,
Another Sunday Funday behind us and more information for us all to share and grow with. I was expecting a wider ranger of answers as this was an IR challenge but the number of entries was fairly low this week, not sure if that's from too much furlough partying or if Linux is again a weak point for responders as well as examiners. With that said our winner this week is Darren Windham, one of our panelists from this week decided to step up to challenge and won!
The Challenge:
You are an internal responder for a hosting provider, almost all of your major systems are in a DMZ to allow customer access. An attacker has breached your network which is CentOS Linux based.You've detected his anomalous traffic to a foreign country as part of a netflow review and you are now worried about lateral movement from the database server you have found. Assuming there is netflow data and a default CentOS install across 10 DMZ based systems what would you do to determine lateral movement.
The Winning Answer:
Darren Windham
Assessment: Assuming a DMZ environment and a default CentOS install then it is likely that auto updates are not enabled and the 9 other servers also have outdated software that allowed the initial breach. Given the environment is a DMZ it is likely that all of the systems have some sort of service open to the internet be it DNS, HTTP/HTTPS, Database, SMTP, etc. Assuming one flat subnet for a DMZ of only 10 hosts lateral movement would likely be easier to accomplish.
Host based Review: To begin on each of the CentOS hosts the various application logs located in /var/log and its various subfolders should be reviewed. By default CentOS will rotate logs weekly and keep 4 weeks worth of previous log files unless changed in /etc/logrotate.conf. These logs should be reviewed to look for signs of account access/creation, services being stopped/started, database connection, etc. A lack of logs or periods of time missing could be signs of log modification. If there are common or shared passwords across the DMZ any activity related to those accounts should also be a priority for review.
Netflow Review:
The netflow data should be reviewed with the focus on traffic to and from the database server. Most normal traffic should be only from the webservers or other application servers accessing the database. Any traffic originating from the database server destined for other systems in the DMZ or out to external hosts all should be reviewed in more detail.
Other thoughts:
In order to provide a clearer picture and to automate the review of this data some sort of correlation/searching tool would be a great asset and allow the responder to search for common terms, IP address, logins, dates/times, etc across all of the data at once. If the DMZ hosts have a path into the internal network via any type of port/protocol all of those systems should be within the scope of the investigation as lateral movement could also occur via ACL’s in a firewall or over a secondary administrative network interface.
This week:
Tomorrow we will start looking over this scenario and discussing how I would handle it.
Another Sunday Funday behind us and more information for us all to share and grow with. I was expecting a wider ranger of answers as this was an IR challenge but the number of entries was fairly low this week, not sure if that's from too much furlough partying or if Linux is again a weak point for responders as well as examiners. With that said our winner this week is Darren Windham, one of our panelists from this week decided to step up to challenge and won!
The Challenge:
You are an internal responder for a hosting provider, almost all of your major systems are in a DMZ to allow customer access. An attacker has breached your network which is CentOS Linux based.You've detected his anomalous traffic to a foreign country as part of a netflow review and you are now worried about lateral movement from the database server you have found. Assuming there is netflow data and a default CentOS install across 10 DMZ based systems what would you do to determine lateral movement.
The Winning Answer:
Darren Windham
Assessment: Assuming a DMZ environment and a default CentOS install then it is likely that auto updates are not enabled and the 9 other servers also have outdated software that allowed the initial breach. Given the environment is a DMZ it is likely that all of the systems have some sort of service open to the internet be it DNS, HTTP/HTTPS, Database, SMTP, etc. Assuming one flat subnet for a DMZ of only 10 hosts lateral movement would likely be easier to accomplish.
Host based Review: To begin on each of the CentOS hosts the various application logs located in /var/log and its various subfolders should be reviewed. By default CentOS will rotate logs weekly and keep 4 weeks worth of previous log files unless changed in /etc/logrotate.conf. These logs should be reviewed to look for signs of account access/creation, services being stopped/started, database connection, etc. A lack of logs or periods of time missing could be signs of log modification. If there are common or shared passwords across the DMZ any activity related to those accounts should also be a priority for review.
Netflow Review:
The netflow data should be reviewed with the focus on traffic to and from the database server. Most normal traffic should be only from the webservers or other application servers accessing the database. Any traffic originating from the database server destined for other systems in the DMZ or out to external hosts all should be reviewed in more detail.
Other thoughts:
In order to provide a clearer picture and to automate the review of this data some sort of correlation/searching tool would be a great asset and allow the responder to search for common terms, IP address, logins, dates/times, etc across all of the data at once. If the DMZ hosts have a path into the internal network via any type of port/protocol all of those systems should be within the scope of the investigation as lateral movement could also occur via ACL’s in a firewall or over a secondary administrative network interface.
This week:
Tomorrow we will start looking over this scenario and discussing how I would handle it.
