After encountering some SNMPv3 servers recently and looking into the differences from a pen. test perspective, I thought it may be worth a quick write-up.
SNMPv1 and v2 do not respond when traffic is sent their way unless there is a valid community string in the message, a fact used by scanners like onesixtyone . So traditionally the theory is unless there's a known community string, the service running has a vulnerability or you can get in-line to sniff traffic, there's not a lot to get from SNMP services.
Turns out that SNMPv3 behaves differently from v1 and v2. Firstly the notion of using community strings for authentication is gone, replaced by username/passwords. Second the traffic can be encrypted to limit sniffing opportunites.
However it's not all bad from a testers perspective! unlike earlier versions SNMPv3 will respond to correctly formatted requests and provide some information about itself as part of the reply. This allows confirmation of the servers existence.
To get these responses there's a couple of different tools we can use. Nmap with version detection will confirm that a SNMPv3 service is running and looking at the traffic in wireshark 
From this there's a couple of interesting pieces of information. The Engine Enterprise ID field seems to identify the server type that's running, net-snmp in this case and the msgAuthoritativeEngineTime parameter shows the time in seconds since the service was started (according to this page ).
In addition to using nmap, it's possible to use the inbuilt snmp tools to get some information out of the service including possible username enumeration and brute-force password attacks.
Issuing the snmpwalk command with an invalid username like so:
snmpwalk -v 3 -n '' -l noAuthNoPriv -u "invaliduser" 192.168.207.142 IF-MIB::ifName
provides the response snmpwalk: Unknown user name
but if we use a valid username and no password like so:
snmpwalk -v 3 -n '' -l noAuthNoPriv -u "snmpUser" 192.168.207.142 IF-MIB::ifName
we get Error in packet. Reason: authorizationError (access denied to that object)
So it's possible by parsing responses to figure out valid usernames for the service.
Update : Here's a ruby script (should work on linux with snmp tools and ruby installed) which iterates over a list of usernames and a list of IPs and attempts to guess whether the username is valid or not snmpv3enum.rb
A similar technique works with specification of passwords which would allow for brute-forcing those as well, (although that said the snmp tools try to stop people choosing passwords less than 8 characters, so unless a dictionary word is used it isn't too likely to be successful.
Additionally for people who're fond of metasploit, I've knocked up a very basic SNMPv3 scanner. At the moment all it does it take a range of IP addresses and say whether a valid SNMPv3 packet provokes a response from the server, but could be handy. it's here.
There's some good references on setting up and using SNMPv3 here, here and here.
