All Entries Tagged With: "penetration"

Using Core Impact Pro Modules

Core IMPACT Pro has the ability to do a full on Network Vulnerability Test, or you can do just Information Gathering using the Network RPT tabs. There’s little attention paid to the modules that make up the suite of tools – and there is so much fun to be had in there. Maybe there is a time when you want to write your own exploits and execute them in Core; or you want to do specific types of discovery and attack – well, Core IMPACT Pro gives you that ability, with tremendous flexibility. I’m going to walk you through a couple of scenarios using the “modules” view, just to show how simple yet excruciatingly effective that portion can be.

Firstly, create a new workspace and click on the “Modules View” tab at the bottom, left of the Modules workspace. You will see a list of folders.

Take time to look around; look in all the folders at all the available tools, and note the modules structure. You’ll be pleasantly surprised at what is available there. If you wanted to perform a specific targeted attack, or information gathering using a single method, you can have some serious fun here.

I’m going to start with an ICMP sweep to identify all “live” hosts on a subnet.

– double click on the “Information Gathering” folder in the modules workspace. The folder will expand.
– double click on the “Network Discovery” folder – that folder expands also!
– double click “Network Discovery – ICMP”. Input the subnet details you want to scan as shown in the image below, and hit “OK”.

Core Impact will perform an ICMP sweep to find hosts, and will attempt to resolve the hostnames. One thing to notice – this is lightening fast!

Once the sweep is done, Core Impact displays the discovered hosts. That’s great, but I want more information so I’m going to attempt to identify the operating systems of the discovered hosts. For a mostly Windows based network (assumption), I prefer using SMB information gathering.

In the modules workspace:

– double click the OS Detection folder
– drag “OS Detect by SMB” and drop it onto your network block (where it says “Network: 192.168.100.0.)

The module will then attempt to find the OS of all the hosts listed in that subnet. In my example there is a mix of operating systems. There were a few that didn’t come up in the SMB scan so there’s more information to be had. Isn’t there always?

In the OS Detection folder there is Nmap OS Stack Fingerprinting. Using Nmap OS Stack Fingerprinting the same way I used the SMB module (drag and drop) I can see some Cisco routers – I’m even given the IOS rev – useful information indeed – plus I see some Macs. I’m going to take a look at a Mac.

When I TCP port scan the Mac I see the Windows File Sharing services running. I’m going to try enumerating users on this machine by dragging the SMB information-gathering module and dropping it onto the host. The SAMR Dumper module gives me some useful information.

Module "DCE-RPC SAMR Dumper" (v1.18) started execution on Wed Jun 24 16:46:45 2009

Retrieving endpoint list from 192.168.100.2

Found domain(s):

. STEVE-SHEAD-C

. Builtin

Found user: nobody

Found user: root

Found user: daemon

Found user: unknown

Found user: lp

Found user: uucp

Found user: postfix

Found user: www

Found user: mysql

Found user: sshd

Found user: qtss

Found user: imap

Found user: mailman

Found user: appserver

Found user: clamav

Found user: amavisd

Found user: jabber

Found user: xgridcontroller

Found user: xgridagent

Found user: appowner

Found user: securityagent

Found user: sshead

The anonymous user has NULL SMB password.

Received 23 entries.

-- Module finished execution after 2 secs.

These usernames can be used in a password attack on this machine if you are so inclined – but I’m not interested in that right now.

I’m going to scan the IP 192.168.0.254 machine since it looks like a Windows 2000 machine (don’t worry – it’s a security test machine). After checking the open ports listed on this machine I’m pretty sure it’s vulnerable to an older remote RPC exploit (ms06-040 worked on this in the old days) to gain access.

– double click the “Exploits” folder in the Modules view
– double click the “Remote” folder and drag the “MSRPC SRVSVC NetrpPath Canonicalize (MS06-040) exploit” onto the host.

If the exploit succeeds, you will see the agent installed just below the host. Depending on whether you chose a “bind” shell or a “reverse” shell will dictate how you want to interact. I love reverse shells personally.

We can connect to the agent and continue the attack. By right clicking on the agent we can invoke an encrypted remote command prompt. The “ipconfig” command reveals that this machine is dual homed – that means there’s more fun to be had.

I’d like to explore the newly found network using Core IMPACT – why not right? This is one of the many fancy features of Core IMPACT. I can now set the installed agent as a “Source” (right click on the agent and select “Set as Source) and pivot any attack from this agent to the new network. This feature can be extended and remote networks can be explored using “agent chaining” – but that’s another story.

I will start the information gathering cycle again on the newly discovered network and perhaps exploit a Windows XP machine on the remote network.

Ok – let’s stop there for now. You can see that I could have branched off in a number of different directions, attacks, scans and much more, just from messing around in the modules area. Sometimes it pays to get granular and use individual scans and attacks. Sometimes it pays to have the flexibility to craft your own exploits and be able to incorporate them into your Core IMPACT environment. The moral here is don’t just play with the automated stuff – though that is a ton of fun – you’re missing so much more by leaving out the modules – and the modules can lead you in some pretty interesting directions, that you wouldn’t otherwise see if everything was automated.

Standard Penetration Testing Checklist

• Introduction
  • Testing organization history and background.
  • Authority to test i.e. Request from company, corporate headquarters or potential buyer of company.
  • Detailed Proposal of test and services that are proposed to be carried out.
  • Capability Statement of the testing organization i.e Core competencies/ limitations/ timescales etc.
  • Tools to be utilized if requested.
• Accreditation Status
  • Interim
  • Re-accreditation
  • Full
• Scope of Test
  • Stage of LifeCyle
    • Interim Operating Capability i.e. Development build/ beta stage.
    • Final Operating Capability i.e. Project at customer acceptance stage.
    • Major upgrade i.e. Software/ hardware update.
  • Test Type
    • Compliance Test
      • Basically an audit of a system carried out against a known criterion. A compliance test may come in many different forms dependant on the request received but basically can be broken down into several different types:
        Operating Systems and Applications: A verification that an operating system and/or applications are configured appropriately to the companies needs and lockdown requirements, thus providing adequate and robust controls to ensure that the Confidentiality, Integrity and Availability of the system will not be affected in its normal day to day operation.
        Systems in development: A verification that the intended system under development meets the configuration and lockdown standards requested by the customer.
        Management of IT and Enterprise Architecture: A verification that the in-place IT management infrastructure encompassing all aspects of system support has been put in place. This is to ensure effective change control, audit, business continuity and security procedures etc. have been formulated, documented and put in place.
        Interconnection Policy: A verification that adequate security and business continuity controls governing the connection to other systems, be they Telecommunications, Intranets, Extranets and Internet etc. have been put in place, have been fully documented and correspond to the stated customer requirements.
        • Full credentials Supplied
        • Full access to Network diagrams and schematics
        • Full access to Configuration scripts and files
        • Compliant with:
          • Customer Defined
          • Government Assurance Pack
          • HIPAA
          • ISO27001
          • Microsoft Lockdown
          • NSA Lockdown
          • Sarbanes Oxley
          • Etc.
    • Vulnerability Assessment
      • Vulnerability assessment is a process of identifying and analyzing a system or network for any potential vulnerabilities, flaws or weaknesses that could leave it open to exploitation.
        • Full credentials Supplied or limited to basic user credentials dependant on level of test
        • Full access to Network diagrams and schematics
        • Full access to Configuration scripts and files
    • Penetration Test
      • A Penetration Test is essentially an evaluation of a system or networks current state of security and its likelihood to be susceptible to a successful attack by a malicious hacker or nefarious user. The process involves enumeration and scanning for any technical flaws or vulnerabilities. After such flaws are found, attempts are then made to penetrate inside the network and gain a foothold. Once this has been established, attempts are then made to utilize trusts and relationships to gain further ingress into the domain.
        • Type of Test
          • White-Box
            • The testing team has complete carte blanche access to the testing network and has been supplied with network diagrams, hardware, operating system and application details etc, prior to a test being carried out. This does not equate to a truly blind test but can speed up the process a great deal and leads to a more accurate results being obtained. The amount of prior knowledge leads to a test targeting specific operating systems, applications and network devices that reside on the network rather than spending time enumerating what could possibly be on the network. This type of test equates to a situation whereby an attacker may have complete knowledge of the internal network.
          • Black-Box
            • No prior knowledge of a company network is known. In essence an example of this is when an external web based test is to be carried out and only the details of a website URL or IP address is supplied to the testing team. It would be their role to attempt to break into the company website/ network. This would equate to an external attack carried out by a malicious hacker.
          • Grey-Box
            • The testing team would simulate an attack that could be carried out by a disgruntled, disaffected staff member. The testing team would be supplied with appropriate user level privileges and a user account and access permitted to the internal network by relaxation of specific security policies present on the network i.e. port level security.
        • Exclusions
          • Social Engineering Attacks
          • Denial of Service Attacks etc.
          • See also Exemptions from test section.
  • Purpose of Test
    • Deployment of new software release etc.
    • Security assurance for the Code of Connection
    • Interconnectivity issues.
    • Deployment of wireless networks on wired LAN.
    • ISO27001/HIPAA etc. Compliance
• Obtain appropriate Network details (dependant on level of test.)
  • Peer to Peer, Client-Server, Domain Model, Active Directory integrated
  • Number of Servers and workstations
  • Operating System Details
  • Major Software Applications
  • Hardware configuration and setup
  • Interconnectivity and by what means i.e. T1, Satellite, Wide Area Network, Lease Line Dial up etc.
  • Encryption/ VPN’s utilized etc.
  • Role of the network or system
• Obtained signed Authority to Test
  • CEO
  • Risk Manager
  • System Manager
  • Data Owners
  • Security Officer
  • Relevant ISP
• Non-Disclosure Agreement
  • Full i.e. All information in relation to this task cannot be distributed/ used in research, training, marketing etc.
  • Limited i.e. Certain information can be used in marketing/ training and research scenarios after agreement has been sort from the customer.
  • None i.e. All information is freely distributable and not under any restrictions whatsoever.
• Special Clearances required
  • Government vetting
  • CHECK Team qualified
  • Mastercard certified
• Known waivers/exemptions
  • Known to Risk Manager
  • Risk Assessments completed
  • Exemptions from test
    • Development builds
    • Joint-owned equipment
    • Laptops
    • Trial Applications
    • Unstable Hosts
    • Supplied Network infrastructure for the test only
• Contractual constraints
  • Are there any Service Level Agreement in place that may affect the scope of the test
  • Waiver letter required for test from contractual partners (this document is required in conjunction with Authority to test above.)
• Local equipment requirement
  • CAT5 taps and speed
  • Fiber taps/converter requirement
  • Local Internet access
    • Filtered
    • Unfiltered
    • Downloads/exports allowed
  • Office space
  • Power available
  • Refreshments
• Local manpower requirement
  • Application administrators
  • Database administrators
  • Network administrators
  • Operating System administrators
• Points of Contact
  • Risk Manager
  • Database Administrator
  • Local Security Officer
  • System Administrator
  • Networking Administrator
  • ISP
  • Note: – All should be named and have appropriate 24/7 contact numbers provided.
• Reporting Timescales
  • During Test
    • Normal
      • Daily Brief
      • Interim Brief
      • End of Test verbal debrief
    • Exceptional
      • Upon identifying Critical vulnerabilities/ exploits
      • Upon identifying previous Intrusion
      • Upon finding child pornography/ other activities legally bound to report.
  • Post Testing
    • Normal timescale
    • Local requested timescale
    • Privacy/Commercial Protective Marking required
    • Distribution List
• Access to Previous tests & reports
  • Compliance Test
    • Reason for test
    • Who carried out
    • When carried out and if any rectification work was completed.
    • Release timescale
      • Start of test – This is important for a Compliance test as previous failings can immediately be re-tested and verified as secured or still vulnerable to exploit etc.
      • During test
      • End of test
  • Vulnerability Assessments
    • Reason for test
    • Who carried out
    • When carried out and if any rectification work was completed.
    • Release timescale
      • Start of test
      • During test
      • End of test
      • This can be important during a vulnerability assessment as it can be used as a guide of how the network has progressed during the time of the last test to the current period. Release of this by the customer may not be in there best interests as it is best to have an independent team to assess all vulnerabilities. The customer can then also assess the overall performance of the testing team and thus its value for money in conducting the test.
  • Penetration Tests
    • Reason for test
    • Who carried out
    • When carried out and if any rectification work was completed.
    • Release timescale
      • Start of test
      • During test
      • End of test
      • Appropriate comment to be made in final report reference receipt of these documents and at what point during the test. This provides mitigation points as the information gained is privileged and was used to gain an unfair advantage in potentially accessing the network. Obviously if the documents were made available after the test, the less weight would be stressed in the final report as they would only be used for reference. This can severely disadvantage the customer as they are potentially disclosing exploitable holes within their network infrastructure. An opposite point of view is the fact that the testing team will verify any fixes that have taken place or that the exploitable hole still exists and still needs attention to mitigate or close. From the customer perspective if an exploitable hole is not discovered it can give an indication that the exploit could possibly be risk assessed and managed.
• Physical inspection
  • Major work areas where the majority of users would utilize the equipment.
  • Network equipment room where all routing infrastructure is housed and secured.
  • Server room if different from the Network equipment room.
  • Testing teams planned area of work.

Information Technology and Security

Information technology and information security are my fields of expertise, and I have the pleasure of working within those fields as a career. The abstract thought process and mix of technical knowledge make it almost like play time. Thinking outside the box is outmoded – you have to think even more abstract since you are trying to see all points of view – from CEO to hacker – from tactical to strategic, and even political.

I’ve posted a lot of information technology and information security related post to this website. I learn from the information I gleen from around the web and I wanted a place where I could refer back, since some of the command line and shortcut stuff is priceless. It doesn’t matter what status I hold at work, I’m always interested in cleaning up my skills, and learning new ones. There should never be a point, even in the executive layer, that we should let go of those skills.

Information Security is an area I have a lot of passion in. I am the Director of Information Technology and Information Security Officer for the company that I work for and, as such, have to keep my finger on the pulse. I have done hacking course and am technically proficient, but I would not say that I am anything other than someone who sees how it can be done, and wants to prevent it happening to the company I work for.

Here’s a Standard Penetration Testing Checklist. See how involved it is, and that is just the entry point. I didn’t write this by the way – why re-invent the wheel, but it’s a great reminder and backbone for penetration testing. All that I am trying to illustrate is the complexity of information security, and that it is all too often overlooked by executives for no other reason than not arming them with enough information. Yes – we should take the blame for some of that. When I presented the base level of hacking techniques to our executive staff I immediately got budget money. I meant to scare them, and boy did I.

You’ll notice in the tech section there is a ton of useful information. This is just a piece of what I find useful – I don’t have time to post it all so I try to post the most interesting – well, to me anyway. More as it comes to me.