Sadly, not all journeys are perfect. Bug bounty most certainly isn’t either. From the report writing needed, i have developed a better way of writing articulate and concise reports. Nailing every needed hammer to showing impact and criticality, but most important of all, be professional and understandable.

It is very clear that misunderstanding and lack of proper communication have been the key to disagreements between researchers and programs/triagers. I must agree the memes that come with it are funny. Like the famous still meme below. LOL.

As much as programs expect the best of reports and proper behavior from researchers, some may not always return the favor in a couple of ways. From my previous experiences and online complaints, i have come up with a couple of ways programs lack professionalism and let down those holding the fort like bosses! Let’s dig in:

Poor communication

Probably the most annoying thing some programs do. I however have a fair share of experience on programs lacking this. No feedback about anything. The same level of communication expected when a researcher is asked to clarify on a report is the same when a researcher asks for clarification about progress and whatnot.

Receiving a report and going quiet while ignoring tons of messages then only responding while awarding a bounty is not cool. So not cool. Program managers should talk to their security team and emphasize the need for proper communication.

Not understanding a vulnerability

While researchers may try their best to explain an issue, experience on the receiving end is a necessity. If the security team does not understand the vulnerability or impact, it going to be a real hustle. I have witnessed cases where the security team claim an sql injection is not possible and closing the report just because they cant verify it. Only to reopen it later on after a mediation request. Security teams not understanding that different vulnerabilities that are solved differently but lead to the same level of compromise are to be handled differently.

A good way of approaching this sort of situation for programs with this sort of thought is reporting a vulnerability once the previous one is resolved. This will make more sense to them.

Fixing an issue before triage(and going silent)

Don’t get me wrong. In cases where a researcher sheds light on a critical vulnerability, it is logical to act fast and fix/remediate. However, when this is done before triage and the program team goes silent, this is a clear sign of unprofessional-ism. Leaving the reporter to explain to the triager how “the vulnerability was there a few minutes ago” is just not fair. Program teams should at least communicate that they saw the impact and acknowledge it as they do a quick fix.

If a program has a habit of doing this, you better “kazam” and do a screen recording clearly indicating the timestamp during vulnerability confirmation.

Reduced payouts

When the teams fail to understand a vulnerability impact and pay out less for its actual worth. Reducing an RCE impact just because the reporter used the commands “id” or “whoami” on the PoC instead of uploading an interactive web shell. Understanding impact makes for better judgement and more stable and well deserved payouts.

Developer/team mistakes

A memorable one was when i got hold of a subdomain and got hold of full project backup. An sqli followed shortly after. However i was slammed with a “The developer was to take this offline but forgot to do so” excuse.

This issues were later on fixed within an hour and the report severity diminished to a mere low. Just because it was meant to be offline. Personal data retrieved from the sqli dated a few minutes back, proving to be very recent and active. But hey, the program is always right, right?

Conclusion

Researchers and not always right. But neither are programs. Finding the common ground and adhering to some professional behavior will however make for a good relationship and increase chances of program loyalty and increased/better reports.

As i am aware not all issues have been highlighted. But only the most common. Its never that hard. Just a gesture of moral responsibility and obligation to be fair.

Stay safe, whom it may concern.

2FA. Defenders of the modern day web applications.

When certain vulnerabilities are exploited and your primary authentication fails, the bad guys now have access to your profile. We may not be in control of data dumps from different corners of the sites we registered. But What if we could still block the bad guys even after they have our credentials?

This is where 2FA comes in. Security researchers have analyzed web applications and realized a layer of protection is needed. Developers also agree. Once the primary authentication is passed, an email is sent to you, an SMS or authenticator code is generated for you to prove you are who you say you are.

Normal Application Logic?

In a bug bounty engagement, i noticed this “application” was terribly secure. Clean! I was unable to find any substantial vulnerability.

Being a logic hunter, i followed the application process and registered for an account with a fake email service (emailondeck.com). (BTW) This has proven to be helpful in scenarios where corporate emails are accepted and gmail/outlook/yahoo are restricted. But anyway…

A confirmation email was sent and the account verified.

On initial login, i enter my credentials and I’m presented with an OTP form (after redirection to /authenticate endpoint).

I enter the OTP sent to my phone and redirected to my /home endpoint. Pretty normal, right?

Where the vulnerability lies

Now that i have used the application correctly, i try the login process with the aim of bypassing the security check (OTP).

I enter the creds and I’m presented with an OTP prompt again.

I tried refreshing the page but still nothing but the prompt.

I press the back button which should take me back to /login but I’m instead redirected to /home, the default landing page after successful authentication. I am presented with the good ol “$username” and i submit this simple report to the program.

Take Home

Test the simplest of functionalities that are meant to protect the user. It just might be in the weirdest of places.

The Fix?

Through a later discovered source code disclosure, it was observed that the developer set a ‘otpverify‘ value to false. The fix was implemented by simply changing that to true.

Path Traversal

When developers do not properly implement the right access controls to files and directories, a web application may be subject to path/directory traversal attacks. This could enable an attacker to retrieve files they are unauthorized to.

Local File Includes

This exploits the applications ability to include certain files in is inherent functionality, allowing reading and executing files on the web server.

This said, it is a proper deduction that path traversal is a subset of LFI.

The Bad

So we can read files and navigate to directories we were not supposed to, big WOW.

However the issue comes with the ability to:

• Read Source code
• Read files outside the web servers application root.
  

Deep Dive

In a previous engagement, i located an interesting file include.php that gave a blank/white page with nothing to display.

Passing this path to arjun to detect possible get parameters, i noticed a parameter “view” returned a different content-length. With the message “incorrect path to csv document”. I guessed this was used to process or parse some csv files that had been uploaded to the server.

The good ol’ ../../../ did not work so i used php wrappers. Over the past couple of years, i learnt that abusing wrappers are a crucial buddy when exploiting LFIs to read files contents. “php://filter/convert.base64-encode” to be specific.

How this works is the filter enables the application to read a resource and pass it to a handler as a base64 encoded entity.

Using curl we can decode this easily to obtain file contents. If it’s a HTML tagged output, pup can be used to process and display this properly.

In some cases, there is need to demonstrate the impact of such a bug. LFI can be leveraged to read files outside the application’s root.

Simple payloads like the proverbial “../../../../../../../etc/passwd” can be applied as a PoC. This can be done directly on the browser address bar or still by abusing the php filter.

Some common files you want to try read may be:

/etc/hosts
/var/logs/access.log (depending on the web server)
/var/logs/error.log (depending on the web server)
/var/logs/php_error.log (depending on the web server)
proc/self/environ
/var/log/messages
/var/log/vsftpd.log
/var/log/sshd.log
/var/log/mail
application server side code to gain a deeper understanding on the app.
N/B Access/error logs are gold as they may reveal other paths.

LFI to RCE

In some rare cases an LFI can be escalated to a sweet RCE. A very good display of such a vulnerability is the Tomcat “GhostCat” [CVE-2020–1938].

Some filters if enabled, can also lead to RCEs. They may include:

upload forms/functions
expect://command
php://file
input:// stream
php://filter

I was however unable to leverage on the input:// stream for this engagement. The Apache process also did not seem to have the other filters enabled.

Since i also had access to some logs, i tried log poisoning to achieve RCE to no avail. However, i have encountered cases where this is possible

and i advice to always give this a try.

This blog post will give different tools to do basic recon in a pentest engagement since no one only relies on one tool. More advanced recon techniques will be covered in part 2 of this blog.

The Tools-set Under Different Categories

Subject 1. Sub domain Enumeration.

In most cases, say in a bug bounty play, most vulnerabilities may not lie in the main domain. Sub domain hunting comes in handy. Lets look at some ways of sub domain enumeration and discovery.

a. Knockpy

Knockpy is a handy tool for this purpose. It uses a wordlist that can be customized to fit your target attack.

b. Sublist3r

As a tool mentioned by pentesters and bug bounty hunters all over the internet, this is a must try.

Sublist3r relies purely on OSINT techniques. It crawls different search engines including Google, Baidu, Yahoo, Ask  etc. Sub domain enumeration also possible via DNSdumpster, Netcraft, Virus total among others.

c. Google dorks

Google as the most popular search engine caches all sorts of websites. This makes it a good tool to find sub domains visited. We just need to know how to ask. Using ‘google.com’ as an example, we can easily do this, exposing the sub domains.

Some good scripts also exist that automate google dorking. Here are 2:

• GoogD0rker

This one automatically launches a series of queries against the specified target. Great OSINT tool. The tool is able to find documents, login pages, backdoors, files by extension, pastebin posts, subdomains etc.

Download it here.

• GooHak

Similar to the above. Find it here.

d. Amass

An OWASP tool for sub domain discovery that uses multiple sources to do this. More info can be found on their git page.

e. Curl one liner

This is a cool script i found on twitter from Ben Sadeghipour‘s tweet. Its pretty simple and uses archive.org to scrape the sub domains.

==>”curl -s “http://web.archive.org/cdx/search/cdx?url=*.testfire.net/*&output=text&fl=original&collapse=urlkey” |sort| sed -e ‘s_https*://__’ -e “s/\/.*//” -e ‘s/:.*//’ -e ‘s/^www\.//’ | uniq“<==

f. Confirm live domains

During my hunts, i found out a number of the domains discovered from tools that do mass scraping do not resolve. In this case, i wrote a simple bash script that given a text file with all the valid sub domains, goes through them all and tries to resolve them and find out which ones don’t. Download it here.

 Subject 2. Web Server Fingerprinting.

culprit: HTTP Methods

a. Curl

Curl is a pretty powerful CLI tool. Despite being used by pentesters to exploit file inclusions (RFI, LFI), command injections, HTTP file uploads etc, it can also be used to identify a HTTP methods allowed on the server. Some servers however have OPTIONS disabled, we can use HEAD instead.

Dangerous methods like TRACE and PUT should not be allowed. On exploitation of PUT, check out NMAP scripts, tools like burp and browser add-ons like poster.

b. NMAP

Weaponizing nmap scripts can come in handy.

c. My rudimentary curl script

I wrote this simple script to print out the response headers for a list of servers in a text file. However if the OPTIONS method is enabled on the server, we can get the list of allowed methods on the server. See it here. This includes a simple http(s) check using wget for the list of servers. As usual, this can be improved/modified.

N/B. netcat, nikto can also be used for this.

culprit: Application Mapping

In an attempt to attack an application, we have to understand its working, architecture and underlying technologies.

Identifying technology used

• Wappalyzer

This is a browser extension that identifies an applications underlying technologies. This may include the language used, development frameworks, CMS, analytics frameworks etc. It runs on both firefox and google chrome.

• Whatruns

Another browser plugin that works the same way. Just a bit more aggressive.

• WafW00f (Firewall discovery)

So we want to actively interact with the target. However different probes might get blocked by a possible security solution like a WAF. If so we can identify the WAF in use by using sandrogauci ‘s tool, WafW00f that can be found here.

Content discovery

• dirb

Very comprehensive directory/file bruteforce tool that uses a custom word list to find the directories or files that exists. This happens to be my favorite.

• dirsearch

Similar to dirb but with some fancy colors for easier status identification. Searches for both files and directories as well. This has the ability to specify extensions. e.g php, txt, rar, zip etc.

• dir buster

Another one by OWASP. With a cool looking GUI, it does file and content discovery with an option to specify custom word list. Also comes with a cool set of word lists. Can be found here

• nikto

From banner grabbing, header analysis, light default directory/file discovery, nikto is pretty handy. Also offers some suggestions and advisory info for why the discovered issues are dangerous.

• Aquatone

It gives a visual representation of the websites listed on a text file. This helps easily map out the best attack surface. For example, makes it easy to find login pages without manually visiting the pages. It takes screenshots of the pages and saves them to a folder. Also includes headers.

It also has other modules i.e. scan, discovery, gather, takeover that will be discussed on part 2 of this blog.

• burp intruder

Burp’s intruder also serves as a multipurpose tool. In this context it can be used to bruteforce files, directories, GET params etc while observing status codes as well as content length.

• The perfect wordlist for the job

All these tools wont give a heavy punch without a good set of word lists. From my research i discovered seclist. Probably as comprehensive as it gets. Coupled with different usernames, passwords, URLs, payloads etc. It earns the ‘ultimate wordlist’ title.

N/B: Discovering ‘hidden’ GET/POST parameters.

During pentesting or bug bounty hunting, the best way to attack a page is on inputs. Hence parameters are really important. If we cant find them on the first look, its possible to try and find the ‘hidden‘ parameters using different tools.

• Arjun

One tool by UltimateHackers comes to mind. Arjun is a script that helps bruteforce these parameters using a word list that can be customized.

• Parameth

This one worked for me a while back. Does the same. But i still prefer Arjun.

culprit: Other search engines

While google might be the most popular search engine, its not the only one. And if you’re gonna be finding vulnerabilities, then you most likely need these 2 as well…

• shodan (shodan.io)

Hands down the ultimate IoT search engine. Same as Google, it uses ‘dorks’ for smarter searches and improve on what it finds. Its right here.

Some common dorks may include:

• country: find devices in a certain country
• hostname: find devices matching the given hostname
• port: find devices on given open ports
• os: return results that match the given OS
• before/after: find results within a given time frame
• city: find devices in a certain city

• Censys (censys.io)

Kinda like shodan, it compares to the fact that it can also search for devices accessible from the internet.

Lets find debian servers running ssh from Africa using the query

“22.ssh.v2.metadata.product:”OpenSSH” AND metadata.os:”Debian” AND location.continent:”Europe”

Have fun with the 100 ways of discovery. Part 2 coming soon.

So its 0045 EAT and im up reading the OWASP Testing Guide V4. I have always used OWASP as my appsec bible, but i have never gone through this whole book. And boy how much wonder it packs.

Anywayyyyyyyy, looking back, i discovered a duplicate vulnerability on an XYZ platform (on hackerone). I was obviously not rewarded, but learnt something in the process. This was a full on XSS. Burp interceptor is able to bypass this client side validation checks, but i needed more. I needed to execute this XSS outside Burp’s context.

Looping in my favorite fuzzing payloads, i tried out a different combo of a million payloads to no avail.Okay, they kinda were 55. An hour later, nothing. However, doing my research, i landed upon this beauty, “XSS polyglot”

Polyglot background

A quick search of the word polyglot defines it as “knowing or using several languages“. “polyglot payloads“, however are, in my simple words, a long payload string that can execute in multiple contexts. This strings contain different types of encodings hence different execution contexts. XSS polyglots are exactly this. Payloads that execute an XSS action as defined in the payload.

Daniel Miessler does a great job with his fuzzing payloads where he has his ultimate XSS polyglot payload.

However, this did not work for me. So much for ultimate. This made me realize that there is not ultimate polyglot, just different ones that might land on the application’s bad side, luckily for us.

A little more research and i realized that JavaScript is a beautiful language with the ability to use an inbuilt function to read decimal values an convert it to ASCII characters ready execution.

To be specific, i abused the ‘String.fromCharCode()’ method.

Full polyglot?

alert(String.fromCharCode(88,83,83))//–%0D%0A%3E%3C/SCRIPT%3E%22%3E%27%3E%3CSCRIPT%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E&redirect=%27%3Balert(String.fromCharCode(88,83,83))//%27%3Balert(String.fromCharCode(88,83,83))//%22%3B%0D%0Aalert(String.fromCharCode(88,83,83))//%22%3Balert(String.fromCharCode(88,83,83))//–%0D%0A%3E%3C/SCRIPT%3E%22%3E%27%3E%3CSCRIPT%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E&token=%27%3Balert(String.fromCharCode(88,83,83))//%27%3Balert(String.fromCharCode(88,83,83))//%22%3B%0D%0Aalert(String.fromCharCode(88,83,83))//%22;

Polyglot breakdown? Sure.

This method takes in the decimal values and converts to string (ASCII). This means ‘alert(String.fromCharCode(88,83,83))‘ gets interpreted as ‘alert(‘XSS’)‘.

Confirmation

I formulated and pasted the polyglot on the naked browser address bar. POPPED XSS. Same was done using ad-dons like:

• LiveHttpHeaders
• Hackbar Quantum

Evidence

Straight out of campus an year ago and i got my first job at a leading fin-tech company in Kenya (thanks to Dr. Bright). Well, i never actually finished school but that’s a romance story for another day.

The thought behinds this?

A few months down the line, we have this ISO 27001 audit around the corner. My team and i preparing tirelessly for the audit like an exam to heaven. However, one thing stands clear. Never leave your laptops unlocked and walk away. That is a major fail on our end, especially from a security perspective.

Okay, we had a Active Directory Group Policy (GPO) for Windows machines, but i was using Linux and was too lazy to always lock my computer. I always forget to lock it.

Tool Discovery

On a completely unrelated quest, i discovered a tool from a friend (Lester) that could enable me to easily connect my android device to my laptop. You can find it here. Setup is fairly easy. And it took me a while to actually discover i was supposed to use the gnome-tweak-took to activate the extension.

All hail, GSConnect

GSconnect is basically a KDE connect, written in GJS for gnome based systems with gnome shell. Some handy features include:

• Sending files between the smartphone and the laptop using the SHH protocol.
• Browsing files on the smartphone.
• Locating your smartphone in case you misplace it.
• Sync the clipboard between the 2 devices (this one is shway!!)

• Sync notifications between the two devices.

• Display smartphone’s battery meter on the laptop.
• Use the phone as a mouse.

• Send SMS from your laptop.

• Control MPRIS2 enabled media players like mplayer and audacious from your phone.
• Run remote commands to your laptop (jackpot)
• etc.

Run remote commands? Bingo!!

Running remote commands on a Linux machine is never a good idea, when you consider the security/convenience see-saw. However, its all about convenience now. Plus a few rules on my local firewall will add a layer of security.

GSConnect enables us to enter custom commands that can be executed from our smartphone. The logic is simple. The client sends the command to the server on the laptop, which executes it as the current user. I was able to use different commands for my tests. This included:

• ping
• loginctl lock-session (lock screen for current user session)
• loginctl unlock-session (unlock screen for current user session)

The commands are not limited to these, but i can blog about smarter ways of doing this if a number of readers request for it. This includes how to use abuse it from a red teamer’s perspective.

On the smartphone, the commands appear as follows and can be used to lock/unlock your laptop.

Fairly interesting tool, huh? This blog title is something i always get asked at work. Now you can walk away and lock/unlock your laptop remotely, and get asked the same question as well ;-). Ooh yeah, and you’ve got to be connected to the same    WI-FI network (both phone and laptop).

Background

The referer request header used by the application to map the previous address of a web request that led to the current page being visit. It basically identifies where users are visiting a page from for analytics, caching and logging purposes, among others…

Narrative

After a few minutes of probing the application, a sub menu with a button to add a new client and its matching source address to the application was revealed.

I fired up burp and tampered the request as i clicked this button. Before entering the necessary fields and submitting the form, we can see nothing more than a couple of headers, including the referer header.

Some tests later, i discovered a reflected XSS on the referer header field. The standard alert(“XSS”) did not yield so i tried out a couple of different custom payloads stored on my mth3l3m3nt.

The JavaScript payload javascript:alert(“I am XSS compliant!”) did the trick. On forwarding the request, we see a page with two options, ‘create’ and ‘cancel’.

The cancel button is mapped to the previous page as suspected using a href tag as seen in the source code.

And finally…

I also did:

• javascript:alert(document.cookie) (popped a session cookie)
• javascript:alert(document.domain) (pops domain property of document object)
• javascript:window.location.href=(“https://www.google.com”) (well…)

What are botnets and why should we care?

Botnets (zombie computers) are a collection of infected machines over the internet which are coordinated by a centralized server, referred to as a command and control (CnC) server. Botnets are fully automated, hence the term BOTnet. They have been in existence for years and have been successfully used by black hat hackers for as long as i can remember. A good example of a worthy malware that was used to raise armies of botnets across the globe was the Zeus malware. With ‘was’ being because most antivirus software detect it and its variants. However, hackers have become more creative and intelligent. They reverse engineer and include polymorphic code that enable antivirus evasion, passing off as ‘clean’.

Some well known bot communication mechanisms

Older bots use the conventional client-server model, where the herds (clients) send a ping to the CnC (server) to make sure it is up and running. Once it affirms server is up, it waits for incoming commands. The clients execute the issued commands/ instructions and report back to the server. The newer models however, use peer-to-peer networks to operate rather than a central server to reduce the risks of having a single point of failure.

Some common botnets include Gameover ZeuS and ZeroAccess .

How are users infected?

Usually, all users are innocent over the web. With little or no knowledge about online safety. This is joy to the heart of every attacker as it increases chances of a successful breach to almost 100%. Bots released by hackers spread across the internet looking to infect victim machines and make them part of the zombie army. An imminent part of an army can be infected in any of two ways:

1. Actively – This involves no user intervention. If a machine infected by a bot, then the bot’s binaries may contain pre-coded mechanisms to find other potential victims on the internet by scanning for machines with known vulnerabilities to exploit. Unpatched machines usually fall under this category. If smart coding is done, users will have no idea what just happened. This is basically the beginning of the end of your computer’s freedom.
2. Passively – This involves some degree of user intervention. A good example may be drive-by-download mechanisms. A user visiting a site is sees some popups saying his antivirus is outdated or a new malware removal tool is available for download. The user downloads the file and installs it. That’s it. All done. Infected, you are! These kind of attacks are made possible by sites running JavaScript or Active X controls. Email attachments, USB sticks may also be viable vectors of malware delivery to spread bots.

Once the machine is infected, it is not part of the botnet yet. It needs to locate the CnC server and establish a connection first. This may be an IP address or a domain name hard coded into the bot binary. It may also do this by obtaining a seed list of other IP addresses of infected machines that know how to communicate with the CnC server. Once this is established, the machine is now part of the zombie army ready to be commanded.

Why raise an army of botnets?

For an attacker, there lies a level of joy in making sure all tasks are automated. Attackers have to minimize individual work load and reduce the number of clicks from their end, while still increasing efficiency and their chances of success. This is done by infecting hundreds of thousands if not millions of computers over the internet. The major strengths of botnets lies in the fact that there is more than efficient distributed computational power and storage, and the delegation of responsibilities available to a CnC server. Like having more than one computer in different parts of the world. Botnets can be used to perform CPU intensive tasks like bitcoin mining or brute-forcing passwords that would take an attacker months on their own private machines. They can also be used as pivot points while attacking open networks, camouflaging the actual perpetrator.

This however does not come easy. For attackers to keep an increasing number of successful infections, they must showcase exceptional skills in the art of persistence. This means that the access to the victims should remain intact and not be detected. Exhibiting the perfect stealth. If a user becomes aware that their machine has been infected, they might reinstall the operating system or take effective measures to clean it up, and this will not play out well for the attacker. To counter this, attackers author malware that evades antivirus software to avoid detection and stay that way for the longest period of time. Once infected, a machine is completely under the attacker’s control and the extent of damage is limitless.

Attackers can be able to perform the following actions on victim machines:

• Steal personal information from victims. These includes, but not limited to: credentials to social media websites, credit card information fed to online banking portals
• Steal data and documents
• DDoS attacks to servers
• Send spam emails
• Distributed computing for password cracking or solving captures etc.

Are other devices affected as well?

Yes. Other devices as well. Phones are no exceptions. Users are tricked into installing malware into there phones. These malware pose as legitimate software (Trojans) often found in third party application stores. The infected devices are even more promising for the bot master when they are rooted(android) or jail-broken (iOS) which means more and better control. From here, attackers control actions of the devices from their CnC servers. Some of these mobile phone bots include GM bot, DroidJack, and Dendroid that are all available for purchase on the net.

Infected devices can allow attackers to: make calls, send text messages, record video and audio, steal user data, open unwanted web pages etc. Again, this is completely under the control of the web master.

IoT devices are also not safe from attacks. A malware known as Mirai has been the subject of discussion among the infosec community ever since September last year when infected devices launched a massive DDoS against a respected security researcher’s blog, Krebsonsecurity. The anatomy of the malware is quite amazing. The source code was made publicly available. Mirai works by exploiting weak security implementations in IoT devices. They scan for these devices that have default configurations or hardcoded credentials in the firmware, for example. These IoT devices later connect back to the CnC server and await command, like the bots they have become.

How do i know i am infected?

For mobile devices, there may be newly installed or removed applications,calls and text messages being sent without you consent, device becoming slow and extreme data usage beyond normal may be signs that you are infected. If this is the case, the best solution may be to wipe the phone and restore factory settings. Flashing the phone with the stock ROM may be another better option.

For Computers, anti-malware tools are a good start. But they only detect known threats. Bots are custom coded and may be harder to detect. But one thing remains clear, they communicate to an external server and receive commands on a regular basis. This makes it possibly for expert analysis to detect by analyzing traffic. Bot-hunters can also be used and passively listen to internet traffic through an infected machine and store logs. The logs can be analyzed to determine breach. The remediation would be shutting down detected CnC servers or preventing communication to them by blacklisting their IPs. A combination of malware removal tools can then be used to clean the PC.

I hope this gives a general overview of understanding botnets.