Sunday, November 29, 2015
Labels:
CTF
,
Information Security
Starting a list to track sites where you can download vulnerable images to learn and for research purposes
Read More
Vulnerable Images
Starting a list to track sites where you can download vulnerable images to learn and for research purposes
| Name | Website | |
|---|---|---|
| VulnHub | https://www.vulnhub.com/ | |
| Hackerdom | http://ftp.hackerdom.ru/ctf-images/ | |
Sunday, November 8, 2015
Labels:
Conferences
,
CTF
,
forensics
,
Information Security
Just a list to start tracking InfoSec Conferences I become aware of:
Read More
Information Security Conferences
Just a list to start tracking InfoSec Conferences I become aware of:
| Event Name | General Theme | Last Known Dates | Website/Email | Status | CTFs |
|---|---|---|---|---|---|
| BloomCON | Forensics and Security | February 5-6, 2016 | Over | Yes | |
| nullcon | Latest attacks, exploits, and vulns | March 11-12, 2016 | nullcon.net | Attendee Registration | Yes |
| BSides Charm City | InfoSec | April 23-24, 2016 | securitybsides.com | Call for Papers | Unsure |
| RVAsec | InfoSec | June 2-3, 2016 | rvasec.com | Call for Papers | Yes |
| RECON | RE and Advanced Exploitation | January 27-29, 2017 | recon.cx | Call for Papers | Unsure |
| hack4 | Tech talks and tech stuff in the old sense of hacker meetups | December 29-30, 2016 | hack4.org | Call for Papers | Unsure |
Wednesday, June 25, 2014
Labels:
data breach
,
disclosure
,
opinion
,
reporting standards
I think it's funny how
organizations are careful to craft public statements in the wake of data
breaches or public exposure that systems were compromised. For instance, the statement above, "no evidence that customer or consumer data
were reached or retrieved," appears to be put forth in an effort to
ease customer concerns. However, as an
information security professional, my first thought was to analyze that
statement through my jaded security lens.
Read More
We've Found No Evidence...Means What Exactly?
For its part, LexisNexis confirmed that the compromises appear to have begun in April of this year, but said it found “no evidence that customer or consumer data were reached or retrieved,” via the hacked systems. The company indicated that it was still in the process of investigating whether other systems on its network may have been compromised by the intrusion.Source: krebsonsecurity.com
 |
| Shucks, I can't find any evidence! |
Thinking critically though, "no evidence was found" could mean
quite a few things:
1) Logs were reviewed and no
exfiltration of sensitive data was observed
2) Systems were scanned with anti-virus and anti-malware software and were reported clean
3) No consumers have complained about their information being compromised (which is typically found by either a consumer having their personal account(s) hijacked and/or unauthorized charges on credit card or banking statements.
2) Systems were scanned with anti-virus and anti-malware software and were reported clean
3) No consumers have complained about their information being compromised (which is typically found by either a consumer having their personal account(s) hijacked and/or unauthorized charges on credit card or banking statements.
Log Analysis
As someone who troubleshoots
various networking issues, when someone tells me they've reviewed the logs and
found no evidence, my first thought is who QC'd the review? In complex security and/or networking issues,
I've found it's extremely helpful to have someone else either assist or vet
your work. We all have varying degrees
of experience and talent which influences the tedious work of analyzing log
files, packet traces, etc. and can result in one person easily noticing
something of interest while another person would miss it entirely.
Are there such certifications in
the area of log analysis? To my
knowledge, there's no industry accepted certification for log analysis like
there is in the way of other certifications like CISSP, Net+, or CEH. So, at most that leaves either a
vendor-specific certification, training, and/or experience.
With vendor-specific training, you
learn the basics of the device/software and maybe there's some advanced
training that takes you on a deeper dive of the product, but most of the time
such training doesn't teach someone how to analyze information and properly interpret the results.
Okay, what about training that
isn't vendor-specific? Now we're
getting somewhere. The type of training
here though would be akin to what an intelligence analyst has to do, which is
crawl through vast amounts of collected informaton to find connections and
correlations. Academically, it's tough to find such training. I did find a couple of related courses on Coursera:
Reasoning, Data Analysis and Writing
Statistics: Making Sense of Data
Reasoning, Data Analysis and Writing
Statistics: Making Sense of Data
Lastly, there's experience, where
over time you've learned to recognize such connections and correlations.
When companies suffer a data
breach, of course junior analysts can assist, but the effort should be overseen
by someone who has had analyst training and/or years of experience. How much experience? For the CISSP it takes five years of
experience and an endorsement, so maybe there could be something along those
lines established.
Scanned Systems
Next, we have the assumption that
machines were scanned and no evidence of malicious software was found. How many machines were scanned? With what tools were they scanned?
There are numerous reports of how
anti-virus based on signatures, although still necessary, is considered an
entry point in terms of an anti-virus defense.
It should be supplemented by software that scans for heuristics as
well. But lately, as Brian Krebs also
reports, there's an entire underground industry developing around the goal of
obfuscating malware payloads so they aren't recognizable. So, if scanning systems for viruses is now as basic an
action as is locking your front door, something more is needed.
This is an area where companies like Carbon Black, Crowd Strike, and Mandiant are making names for themselves. Although their tools are reactive in nature, they are oriented toward Incident Response and identifying the method of exploit and what systems and data were touched. Combining the output from those tools with the log analysis above should provide a picture of what systems and data were affected.
This is an area where companies like Carbon Black, Crowd Strike, and Mandiant are making names for themselves. Although their tools are reactive in nature, they are oriented toward Incident Response and identifying the method of exploit and what systems and data were touched. Combining the output from those tools with the log analysis above should provide a picture of what systems and data were affected.
Reporting Standards
If a company has performed both the log analysis and has the scanned system output, the next course of action would be public disclosure. This presents an issue though because if there is suspected criminal activity, law enforcement would be involved and the general rule is that information is prohibited from disclosure in ongoing investigations. However, just saying "no evidence found" isn't enough.
To address the issue on both fronts, disclosure standards should be defined so companies can incorporate those standards into their incident response plan. By the way, if you work for a company that doesn't have one, you might want to start building one now.
The U.S. does have data breach disclosure notification laws, but nothing specifying how the information should be presented to the public or what details can be included when law enforcement is or isn't involved. Have a look at the link above and you'll see most states have individual statutes specifying what constitutes sensitive data and when individuals should be notified. And even within that context, states handle data breach disclosure handling differently. A federal law would provide clear guidance for states to incorporate into their own codified laws and for companies to use when these events occur.
Maybe then we can get clarity on "no evidence was found"
To address the issue on both fronts, disclosure standards should be defined so companies can incorporate those standards into their incident response plan. By the way, if you work for a company that doesn't have one, you might want to start building one now.
The U.S. does have data breach disclosure notification laws, but nothing specifying how the information should be presented to the public or what details can be included when law enforcement is or isn't involved. Have a look at the link above and you'll see most states have individual statutes specifying what constitutes sensitive data and when individuals should be notified. And even within that context, states handle data breach disclosure handling differently. A federal law would provide clear guidance for states to incorporate into their own codified laws and for companies to use when these events occur.
Maybe then we can get clarity on "no evidence was found"
 |
| Don't worry. Every company says they didn't find anything... |
Thursday, June 12, 2014
Labels:
back track 5
,
metasploit
,
postgresql
And we have to modify the database.yml file to reflect the new port value as well. While we're there though, why not change the default database credentials?
To test the connection, connect from another BackTrack/Kali session via these steps:
Read More
BackTrack 5r3: Make it a Team Effort
Background
In October 2012, I was prepping for our finals round in the Global CyberLympics competition (where we took 2nd place).
From previous practice sessions, my team and I agreed the best way to distribute information rapidly (and visually) among team members was to use Armitage's Team Server. At the same time, a couple team members had custom tools they wanted to use, which presented a problem: running those custom tools would not feed the results into the central Team Server instance. So, we needed a way to have them retain the ability to use their own stuff, but still share that information to everyone. Our solution was to identify one team member to not only run Armitage Team Server, but also make the Metasploit database externally accessible. Side note: for those not already familiar, the metasploit framework (msf) does not have a "free" GUI. Armitage was developed by Raphael Mudge to provide a GUI as well as enable easy team operations. Read more at Raph's Armitage website: fastandeasyhacking.com.
From previous practice sessions, my team and I agreed the best way to distribute information rapidly (and visually) among team members was to use Armitage's Team Server. At the same time, a couple team members had custom tools they wanted to use, which presented a problem: running those custom tools would not feed the results into the central Team Server instance. So, we needed a way to have them retain the ability to use their own stuff, but still share that information to everyone. Our solution was to identify one team member to not only run Armitage Team Server, but also make the Metasploit database externally accessible. Side note: for those not already familiar, the metasploit framework (msf) does not have a "free" GUI. Armitage was developed by Raphael Mudge to provide a GUI as well as enable easy team operations. Read more at Raph's Armitage website: fastandeasyhacking.com.
I also figured I'd change the default listening port and default database credentials since the database would be externally accessible. You can run Metasploit with different database management systems, but this article's focus is only if it's run on PostgreSQL.
Changing the default port
I decided to make the listening port a higher port, but because I was lazy, it went from 4444 (the default) to 44441.
NOTE: the default port varies depending on what BackTrack distro you're using. In the one I downloaded from the BackTrack Linux site, the default port was 4444. In the screen caps below I'm using a BT distro from Black Hat. To find out what port yours is listening on, run this command:
To change the port bindings, there are two areas where this can be modified, in the postgresql.conf and the setenv.sh files. Both files are in the directory /opt/metasploit/postgresql/, with postgresql.conf located in the ../postgresql/data directory and setevn.sh located in the ../postgresql/bin directory.
Many configuration settings are available in the postgresql.conf file, including an option to change the default port:
You can either change the port here, or if you notice at the bottom of the file, there's a message advising that settings that can be changed in the setenv.sh file instead. Since the port parameter is commented out in the postgresql.conf file, I suggest only focusing on the port value in the setenv.sh file. Change the PGPORT parameter to what you want:
NOTE: the default port varies depending on what BackTrack distro you're using. In the one I downloaded from the BackTrack Linux site, the default port was 4444. In the screen caps below I'm using a BT distro from Black Hat. To find out what port yours is listening on, run this command:
To change the port bindings, there are two areas where this can be modified, in the postgresql.conf and the setenv.sh files. Both files are in the directory /opt/metasploit/postgresql/, with postgresql.conf located in the ../postgresql/data directory and setevn.sh located in the ../postgresql/bin directory.
Many configuration settings are available in the postgresql.conf file, including an option to change the default port:
You can either change the port here, or if you notice at the bottom of the file, there's a message advising that settings that can be changed in the setenv.sh file instead. Since the port parameter is commented out in the postgresql.conf file, I suggest only focusing on the port value in the setenv.sh file. Change the PGPORT parameter to what you want:
There's one other area we need to amend to reference the new port value, and that's the postgresql startup script. This is located at:
/opt/metasploit/postgresql/scripts/ctl.sh
Change the port value to match what you set in the setenv.sh file.
Last step - either reboot to restart the postgres process, or restart it manually.
IMPORTANT!
Now that we've changed the PostgreSQL settings, we need to make metasploit framework aware by changing the postgres_port value in the metasploit properties file, located at:
/opt/metasploit/postgresql/scripts/ctl.sh
Change the port value to match what you set in the setenv.sh file.
Last step - either reboot to restart the postgres process, or restart it manually.
IMPORTANT!
Now that we've changed the PostgreSQL settings, we need to make metasploit framework aware by changing the postgres_port value in the metasploit properties file, located at:
/opt/metasploit/properties.ini
And we have to modify the database.yml file to reflect the new port value as well. While we're there though, why not change the default database credentials?
Changing default credentials
Navigate to /opt/metasploit/config
You can change the database credentials (and the port) by editing the database.yml file and changing the relevant parameters under the production header.
Once you change these settings and launch the metasploit framework console (msfconsole), enter the db_status command to verify database connectivity is successful. If you see an error, you may have missed a step above.
Once you change these settings and launch the metasploit framework console (msfconsole), enter the db_status command to verify database connectivity is successful. If you see an error, you may have missed a step above.
Modifying PostgreSQL: Listen externally
Change entries in
/opt/metasploit/postgresql/data/pg_hba.conf
The instructions advise you how new entries in the control list should be formatted:
The instructions advise you how new entries in the control list should be formatted:
When you scroll down, you'll see the lines specifying what connections the database permits. NOTE: I've added the second line under IPv4.
You can permit access to all databases (the first all), from all users (the second all), on all addresses. The line item I added allows external access to all databases from all users on all IP addresses this BackTrack instance, but you can make it more granular for tighter control by changing the database and user values to what you have in the database.yml file above. Furthermore, you could lock down the subnet or put multiple line items to allow only your teammates to connect.
Now we edit the file
You can permit access to all databases (the first all), from all users (the second all), on all addresses. The line item I added allows external access to all databases from all users on all IP addresses this BackTrack instance, but you can make it more granular for tighter control by changing the database and user values to what you have in the database.yml file above. Furthermore, you could lock down the subnet or put multiple line items to allow only your teammates to connect.
Now we edit the file
/opt/metasploit/postgresql/data/postgresql.conf
Uncomment the line "listen_addresses". You'll need to change listen_addresses to '*':
Restart PostgreSQL or reboot and now you're listening for external connections!
End Result
Now you can accept external requests from others to log into your msf database, and the output from tools they run will populate your database.
To test the connection, connect from another BackTrack/Kali session via these steps:
- Launch msf console
- Type command string similar to "db_connect msf3:20394965@192.168.229.133:7338/msf3dev"
- db_connect, msf command to connect to another database
- msf3:20394965, username and hash set in the database.yml file above
- IP address of remote instance
- Port database is listening on
- /msf3dev, the name of the database to connect to
If you like this post and it works for you, or if you have any other related tweaks please let me know in the comments!
Friday, April 18, 2014
Labels:
CTF
,
forensics
These are the two clues provided to help you get started:
Read More
Write-Up: [SOLVED] SANS Easter Challenge - The Mystery of the Missing Easter Bunny
WARNING
Complete spoilers ahead! If you want to try the challenge first on your own, do not read this post. You've been warned.
Bunny-Napped!
Scenario: The Easter Bunny has been kidnapped, and YOU have to save him! Quickly collect yourself and help save him. Put on your detective hat and start investigating the clues provided.
These are the two clues provided to help you get started:
- An intercepted message from the bunny-nappers
- Ciphertext:
- Dsemvnqwlnmmzvi! Cc jagpbussnpwg tfgzvlroknt mlta cfwjgkr vqu phywl bfx kni Rxutrk Tztydi btsj lh tux asmhfesuygp qf gai Piiuii Zieoqrvlxd. Bxf gioqvkclf aegm ivgtkwfcwlyr fpmd btgxiubpdrw, xsidlw ku cbr! Vhngod nes cfav tlqd jhvv, ide M yutr fv wnl jfv. Xfvv ow geg fvgew xqsx fl xub Gafmic Kxbpckrtb: jtgi://ahe.ifglxiflnugbsya.dp/iryxro-ehneppvwf-xyk-qlpveer-sq-bxf-qzywvki-enlxpz-rvree/
- Hva aoh emvm yu? Pvgzr x eozfiyb qoh ckx zb mnbp :)
My Methodology
First try: the lazy way. I snagged the ciphertext and threw it in Decrypto by Blisstonia software in the hopes the answer would be solved by automation. No such luck.
Second try: experience based on past crypto challenges. I downloaded Cryptocrack, which I heard about in the CyberPatriot competition and ran it through a couple ciphers. Again, no such luck.
Winning try: tackling the mp3 first.
This Sounds Weird
After downloading the mp3, I listened to it, and it had that weird sound I can only describe as recognizing when something is played backwards. To see if that hunch was right, I downloaded Audacity and used the Reverse effect. Playing it after that effect revealed someone speaking letters in the NATO phonetic alphabet. When you record all the letters it instructs you to access a dropbox user content URL.
Image Analysis
Visiting the dropbox URL invokes a download of an image of John Malkovich holding a gun to a bunny's head. The file was a jpeg, so I figured there had to be something embedded in either the metadata or the picture itself via steganography. I didn't feel like downloading a piece of software for analysis, so I searched for photo forensics and came across this handy site: http://fotoforensics.com. Once you upload the picture and look at the metadata output, you'll see in the Comment field this description:
The ciphertext is created using the famous Vigenere cipher, once considered unbreakable. The key to reveal the cleartext is a combination of the a town located at the X Y coordinates where this picture was taken, and the make of the camera.
Obtaining the Vigenere Key
If you pop in the coordinates to mapping tools, you'll see it locates the town you need. Adding the town name only plus the make with no spaces provided the key.
Last Step
Deciphering the text reveals a URL for you to visit along with a message of thanks for assisting and instructions for you to let the Easter police know what you've found. When you visit the URL, you'll see a password prompt, into which you can enter the Vignere key and get a nice picture of the Easter Bunny waving and saying how thankful he is that you helped save him!
I submitted more details of my write-up in response to the challenge, but alas, I was too late. It was fun though! Thanks to the SANS folks to continue to provide these fun contests!
Tuesday, April 1, 2014
Labels:
security
Read More
Spring Cleaning the Security Settings
Clean Up Those Security Settings!
I Decided did at a minimum each Spring I would endeavor to review my security settings across websites, apps, browser, and devices to make sure all security switches were enabled to the fullest extent possible. I'm posting this entry as a cheat sheet of sorts to Quickly jump to security settings pages. If you're aware of other settings pages That should be added, please submit them in the comments below!
Last Update: 10 SEP 2014
Account Security
Enable Two-Factor Auth (list maintained by others)
Google Security Settings (make sure you're signed in)
Google Apps Connected (revoke access to the ones you no longer use)
Google Drive Apps (click on the settings gear, and click on "Manage Apps")
Google Location History (turn on / off)
Google Picasa Settings (that Affects your G+ photos)
Google Music (authorize / de-authorize devices)
Google Web History (tracks your searches)
YouTube (connected accounts)
GitHub (connected apps)
Twitter (connected apps)
Dropbox (connected devices)
Device Security
Amazon Registered Devices (Instant Video / Prime)
Browser Security
Friday, March 21, 2014
Labels:
packet analysis
,
Wireshark
Since the packet details are structured according to layer-specific information, I can quickly expand a collapsed section related to the target of my search. Pro-tip: this is where understanding networking and application behavior is really helpful. Don't worry if you're not familiar, because this is also what helps you learn how the packets are placed onto the wire. Let's dive into this one layer at a time.
What's funny about this part of the packet view is that if you take away the bracketed lines, there's not much info left! Interface ID, Encapsulation Type, Arrival Time, Epoch Time, Frame Number, Frame Length, and Capture Length. I'm still learning, of course, but what I've found is the most important is the Frame Number. When troubleshooting a network communication issue, it's extremely helpful to guide someone else through the packet capture using the Frame Number as a point of reference.
With or without expanding the Ethernet header, we can see the source MAC address and destination MAC address. This is handy when troubleshooting an outbound packet, because you can see where the packet was destined to reach. Typically, this destination MAC belongs to the default gateway, but it depends on the network topology.
What's nice in troubleshooting as well is that the first six hexadecimal digits are parsed by Wireshark to display the user-friendly NIC identifier, commonly referred to as the manufacturer's registered identification number. If you know your device, then you can easily recognize the packets sent and received by your device based on MAC. Why is this important? Load-balanced clusters that share a virtual IP address.
In the IP header, we see the source and destination IP addresses. When dealing with packets on WAN links, sometimes people utilize the DiffServ Code Point value (DSCP) as a Quality of Service mechanism to classify packets into prioritized buckets. Higher-priority packet buckets get processed first.
Focusing on the highlighted line in blue, we quickly see the source port and destination port. From those numbers, it's typically easy to recognize which is the sender and receiver. When a host sends a packet to another host, the port chosen on the source is a randomized ephemeral port higher than port 1024. The destination host in this case is a webserver, which makes sense since we're looking at an HTTP packet, and the destination port is 80 (the normal server port over which HTTP connections are established).
In the exploded view, we see the Flags section which indicates certain information related to the nature of the connection. For instance, the Push flag is set, which is an indicator that the packet should be processed up to Layer 7 because the source is sending data to the destination. In this packet, that data is the URL in the GET request. It's at this part of the packet attacks like the Christmas Tree attack are initiated against a webserver. This video explains it perfectly:
Expanding the HTTP layer, we see the formation of the GET request. Bonus points on my imaginary scoreboard if anyone can let me know in the comments whether the request is explicit or transparent. In the GET request, I can see the HTTP protocol version used (1.1) and the path of the request. The path in this packet is "/", meaning it was a request for the root web directory.
The Host Header instructs the server to send the root web directory back for www.msn.com. Can anyone guess why the Host Header is important? Think about it for a second, and then you can check your answer.
Below the Host Header, we can see other HTTP Request Headers the browser of the source host sent to the webserver. The ones to discuss are User-Agent, DNT, Accept, Accept-Encoding, and Accept-Language, but head on over to my HTTP Headers post if you're interested. In this here post, we're focusing on the packets!
At the very bottom of the HTTP layer of the packet, you can see some helpful bracketed information Wireshark parsed out for us. We can see the Full request URI, which means the request was observed as http://www.msn.com. And we see that the webserver responds to this packet [Frame 294, see above] in Frame 389. That allows you to scroll through the packet capture to Frame 389 to see what the server sent back.
Read More
Packet Analysis 101 - Wireshark's Packet Details
"The time has come," the Walrus said,You've already seen how to use Wireshark to take a packet capture, how to set capture filters, and how to set display filters. In this post, we're going to talk about Wireshark's Packet Details View.
"To talk of many things:
Of bits-and bytes-and frame headers--
Of trace routes-and pings...
Packet Details
What's nice about Wireshark's Packet Details View is that it parses out the packet in easy to read sections that map to the OSI model:Since the packet details are structured according to layer-specific information, I can quickly expand a collapsed section related to the target of my search. Pro-tip: this is where understanding networking and application behavior is really helpful. Don't worry if you're not familiar, because this is also what helps you learn how the packets are placed onto the wire. Let's dive into this one layer at a time.
Packet Frame Header
Let's expand the Frame Header line and see what we get.
Some important things to note first before we discuss too many details. When you expand a "layer" in the Packet Details View, anything in brackets is something not found in the actual packet, but is inserted by Wireshark during the loading of the packet capture. Fun stuff to note for later includes the time delta and coloring rule.What's funny about this part of the packet view is that if you take away the bracketed lines, there's not much info left! Interface ID, Encapsulation Type, Arrival Time, Epoch Time, Frame Number, Frame Length, and Capture Length. I'm still learning, of course, but what I've found is the most important is the Frame Number. When troubleshooting a network communication issue, it's extremely helpful to guide someone else through the packet capture using the Frame Number as a point of reference.
Ethernet Header (OSI Layer 2 - Datalink)
With or without expanding the Ethernet header, we can see the source MAC address and destination MAC address. This is handy when troubleshooting an outbound packet, because you can see where the packet was destined to reach. Typically, this destination MAC belongs to the default gateway, but it depends on the network topology.
What's nice in troubleshooting as well is that the first six hexadecimal digits are parsed by Wireshark to display the user-friendly NIC identifier, commonly referred to as the manufacturer's registered identification number. If you know your device, then you can easily recognize the packets sent and received by your device based on MAC. Why is this important? Load-balanced clusters that share a virtual IP address.
IP Header (Layer 3 - Network)
TCP Header (Layer 4 - Transport)
Because HTTP is a TCP-based protocol, we have a TCP header present.
Focusing on the highlighted line in blue, we quickly see the source port and destination port. From those numbers, it's typically easy to recognize which is the sender and receiver. When a host sends a packet to another host, the port chosen on the source is a randomized ephemeral port higher than port 1024. The destination host in this case is a webserver, which makes sense since we're looking at an HTTP packet, and the destination port is 80 (the normal server port over which HTTP connections are established).
In the exploded view, we see the Flags section which indicates certain information related to the nature of the connection. For instance, the Push flag is set, which is an indicator that the packet should be processed up to Layer 7 because the source is sending data to the destination. In this packet, that data is the URL in the GET request. It's at this part of the packet attacks like the Christmas Tree attack are initiated against a webserver. This video explains it perfectly:
HTTP (Layer 7 - Application)
At last, we see the application layer! This part of the packet can help us get a measure of what the source did and how the server may respond. In this packet we see HTTP, but in future posts we'll discuss other Layer 7 protocols and the communication involved.
The Host Header instructs the server to send the root web directory back for www.msn.com. Can anyone guess why the Host Header is important? Think about it for a second, and then you can check your answer.
Below the Host Header, we can see other HTTP Request Headers the browser of the source host sent to the webserver. The ones to discuss are User-Agent, DNT, Accept, Accept-Encoding, and Accept-Language, but head on over to my HTTP Headers post if you're interested. In this here post, we're focusing on the packets!
At the very bottom of the HTTP layer of the packet, you can see some helpful bracketed information Wireshark parsed out for us. We can see the Full request URI, which means the request was observed as http://www.msn.com. And we see that the webserver responds to this packet [Frame 294, see above] in Frame 389. That allows you to scroll through the packet capture to Frame 389 to see what the server sent back.
Conclusion
This post focused on a single HTTP packet and explained Wireshark's Packet Details View of that packet. If you have any questions or just want to let me know how awesome it was to read this post, please leave a comment below!
Subscribe to:
Posts
(
Atom
)
